X  AD-A100  081  AIR  FORCE  INST  OF  TECH  WRIGHT-PATTERSON  AFB  OH 
JOVIAL  (J73)  TO  ADA  TRANSLATOR  SYSTEM.  (i/> 

DEC  80  R  L  BROZOVIC 
UNCLASSIFIED  AF I T /GCS/EE/ 80D-5 


SCHOO— ETC  F/6  9/2 
NL 


"  ~TT'l  4,,T;e.n t  has  cjpprowa 
uv  oabV  reioae*  cuvi 


-•l.ijnbiitioi) 


is  nnllmlwd. 


DEPARTMENT  OF  THE  AIR  FORCE 
AIR  UNIVERSITY  (ATC) 

AIR  FORCE  INSTITUTE  OF  TECHNOLOGY 


Wright-Patttrson  Air  Fore*  Bast,  Ohio 


81  6  30 


j  AFIT/GCS/EF/80P- 


i  t  i 

^Jl^JOVIAL(J73)  TO  ADA 

/  TRANSLATOR  SYSTEM 

/ 

/ 

// 


THESIS 


Presented  to  the  Faculty  of  the  School  of  Engineering 
of  the  Air  Force  Institute  of  Technology 
Air  Training  Command 
in  Partial  Fulfillment  of  the 
Requirements  for  tne  Degree  of 
Master  of  Science 


i  /  i  / 


by  .  | 

i  Richard  L .j  Brozovic ,  B.S. 
Capt  USAF 

Graduate  Computer  Systems 
December  1980 


i 


Approved  for  public  release;  distribution  unlimited. 


« 


t 


Preface 

I  have  been  interested  in  programming  languages  since 
my  first  courses  in  computer  science  at  the  undergraduate 
level.  With  the  introduction  of  Ada,  1  immediately  became 
interested  in  the  future  of  Ada  and  the  development  of 
software  tools  to  support  the  Ada  environment.  The  design 
and  development  of  a  system  to  translate  Jovial(J73)  into 
Ada  provided  me  with  an  excellent  opportunity  to  exercise 
some  of  the  compiler  techniques  that  1  have  studied  and  also 
explore  some  of  the  concepts  of  langua0e  translation.  L 
also  had  the  opportunity  to  learn  another  language,  a’7j ,  and 
become  involved  with  the  identification  of  deficiencies  in 
the  still  developing  compiler.  All  considered,  1  enjoyed 
the  project  immensely. 

During  the  design  and  development  of  this  translation 
system,  I  received  help  from  many  sources.  The  Avionics 
Laboratory  of  the  Air  Force  Wright  Aeronautical  Laboratories 
(AFWAL/AA)  sponsored  this  project  and  several  people  deserve 
my  thanks.  Major  Dan  Burton  was  the  project  sponsor  and 
provided  considerable  guidance  and  information  regarding 
J73.  Mr  Mike  Burlakoff  was  also  of  great  help  in  learning 
J73.  Many  other  people  within  the  Avionics  Laboratory  also 
provided  help  from  time  to  time.  The  sponsorship  and 
support  of  the  AFWAL/AA  were  greatly  appreciated. 
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1  would  also  like  to  thank  my  thesis  advisor,  Lt  Col 
Jim  Rutledge,  who  provided  technical  support  on  Ada.  Major 
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Mike  Viirth  also  deserves  my  thanks  for  his  assistance  in  the 
areas  of  formal  language  theory.  Thanks  also  goes  out  to 
many  other  AFIT  instructors  and  fellow  students  who  provided 
insight  and  guidance  during  the  design  and  development  of 
the  project. 

Finally,  there  are  two  other  persons  that  deserve  a 
special  thanks  for  their  part  in  my  success.  My  wife  Pat 
shared  the  good  times  with  me  and  was  there  to  support  me 
through  the  hard  times.  Her  encouragement  was  invaluable 
during  my  entire  time  at  AFIT.  The  other  person  of  great 
importance  to  me  is  my  son,  Jason.  Altno^h  he  did  not 
understand  why  I  could  not  always  give  him  the  attention  he 
wanted,  when  we  did  spend  time  together,  we  enjoyed  lite 
greatly . 
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Abstract 

In  recent  years  the  Air  Force  has  developed  a  standard 
programming  language,  J73,  for  use  in  embedded  computer 
systems.  Now  that  the  Air  Force  has  a  considerable 
investment  in  systems  that  are  currently  being  developed 
with  J73,  the  Department  of  Defense  has  selected  a  high 
order  programming  language,  Ada,  that  will  become  the 
standard  for  programming  embedded  computer  systems 
throughout  the  Department  of  Defense.  Also  under 
development  is  the  definition  of  a  support  environment  for 
Ada.  One  of  the  tools  of  this  support  environment  should  be 
a  translator  that  will  produce  Ada  source  programs  from  J73 
source  programs  (Ref  4). 

The  subject  of  this  research  project  was  the  design  and 
development  of  a  Jovial(J73)  to  Ada  Translator  System, 
(JATS) .  The  resulting  system  accepts  J73  programs  and 
produces  equivalent  Ada  programs  to  tne  extent  possible 
while  identifying  segments  of  J73  code  that  were  not 
translated.  This  project  made  use  of  language  parsing 
techniques  and  various  data  structures  to  support  the 
translation  process.  Several  problem  areas  are  identified 
with  possible  solutions.  The  translator  system  should  be  a 
useful  tool  in  the  transition  from  J73  to  Ada. 


I  Introduction 


In  recent  years  the  Air  Force  and  Department  of  Defense 
(DoD)  have  initiated  efforts  to  adopt  standard  programming 
languages  in  order  to  reduce  the  cost  of  software 
development  for  embedded  computer  systems.  Embedded 
computer  systems  are  an  integral  part  of  a  larger  weapon 
system,  such  as  a  flight  control  computer  in  an  aircraft. 
Some  of  these  embedded  systems  are  so  unique  and  specialized 
that  none  of  the  programming  languages  approved  for  use  in 
Air  Force  systems  have  been  appropriate  for  programming 
these  systems.  As  a  result,  new  programming  languages  have 
been  introduced  which  compounds  the  problems  of  software 
development.  In  an  effort  to  reduce  software  development 
costs  the  Air  Force  has  developed  J7  3  which  is  a  derivative 
of  Jovial,  Jules'  Own  Version  of  the  International  Algebraic 
Language  (Ref  1  :39).  As  a  result,  the  Air  Force  has  a 
considerable  investment  in  systems  that  are  currently  under 
development  with  J73. 

In  a  somewhat  later  effort,  the  DoD  also  initiated  the 
development  of  a  DoD  standard  high  order  language  for 
programming  embedded  computer  systems.  In  ^pril  1 9 7 y ,  DoD 
selected  Ada  as  the  language  and  in  July  1980  released  a 
proposed  standard  for  the  language.  In  the  near  future,  Ada 
is  supposed  to  replace  J73  on  the  list  of  approved 
programming  languages  for  embedded  computer  systems 
(Ref  13).  Also  currently  under  design  is  the  definition  of 
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a  support  environment  for  Ada  which  should  include, 
other  software  tools,  translators  for  present  languages 

(Ref  4)  . 

Although  direct  translation  of  existing  software  m.  ■ 
not  produce  production  quality  software,  a  translator  which 
performs  the  bulk  of  the  translation  can  still  be  a  valuable 
aid  in  the  transition  to  a  new  programming  language.  It  can 
save  valuable  time  by  reducing  tiie  amount  of  h.i.u.i 
translation  that  is  required  and  identifying  those  areas 
that  do  require  manual  translation.  The  Avionics  Laboratory 
of  the  Air  Force  Wright  Aeronautical  Laboratories  (AFWAL.'AA) 
has  a  requirement  for  a  J7J  to  Ada  translation  system  which 
should  directly  translate,  to  the  extent  possible,  J7j 
programs  into  an  equivalent  Ada  program  and  identify  those 
segments  of  code  that  were  not  fully  translated. 

Tne  purpose  of  this  research  project  was  to  design  and 
develop  a  translator  system  that  would  produce  equivalent 
Ada  programs  from  J7J  programs.  The  system,  called  J ATS  for 
Jovial(J73)  to  Ada  Translation  System,  is  a  software  product 
which  was  implemented  on  the  AFWAL/AA  DecSy s L e n- 1 0  and 
produces  Ada  text  files. 

The  majority  of  the  work  in  producing  JATS  was  in  tiie 
software  design  and  development.  There  are  three  functional 
units  of  JATS:  (1)  parser  module,  (2)  translation  module, 
and  (3)  prettyprint  module.  The  parser  module  processes  the 
input  language  and  constructs  a  parse  tree,  an  internal 
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representation,  of  the  program.  The  translation  modu. «. 
manipulates  the  parse  tree  to  construct  an  equivalent  AT; 
program.  The  prettyprint  module  uses  tne  results  of  tin- 
translation  to  produce  a  formatted  text  file. 

The  parser  was  developed  from  a  software  pacKc.e  fro' 
Lawrence  Livermore  National  Laboratory  (LLNL)  (Kef  Id'). 
This  package  allows  the  user  to  develop  a  tab  1  e- d r  i : . 
parser  from  a  specification  of  the  language-  syntax  wit.: 
which  the  user  can  develop  a  language  processor.  For  t 
project,  the  parser  is  used  to  construct  a  parse  tree, 
tree  structure  representing  the  input  progra  . 

The  translation  routines  process  the  parse  tree  a:,: 
produce  a  modified  tree  that  represents  an  equivalent  A  a.: 
program.  Finally,  the  prettyprint  routine  produce > 
formatted  text  file  using  the  su0gested  torxati::, 
conventions  in  the  Ada  reference  aanua 1  as  much  as  possible  . 

The  remainder  of  this  document  describes  the  Various 
parts  of  the  design  and  development  of  JAIF.  Chapter  11 
defines  the  requirements  specified  by  the  resource,  project 
sponsor,  AFWAL/AA.  Chapter  III  presents  the  systems 
analysis  that  was  performed  prior  to  development.  Chapter 
IV  describes  the  software  development.  Cnapter  V  presents 
the  results  of  this  project  and  recommendations  for  further 
work.  Several  appendices  provide  additional  information  for 
the  interested  reader.  Appendix  A  briefly  describes  the 
LLNL  software  package.  Appendix  B  defines  the  syntax  of  tne 


j73  language  and  identifies  those  language  productions  that 
have  been  translated.  Appendix  C  contains  a  description  of 
JATS  and  was  designed  to  be  a  system  maintenance  aid. 
Appendix  D  is  a  user's  guide  and  Appendix  E  is  an  example 
J73  program  and  its  translated  Ada  version. 

In  the  remaining  discussions,  for  the  purpose  of 
clarity,  reserved  words  and  specific  data  names  will  be 
capitalized  and  will  be  discernable  from  context. 
Nonspecific  elements  of  the  J73  language  will  be  enclosed  in 
angle  brackets.  For  example,  <name>  represents  any  valid 
J73  identifier.  The  elements  of  J73  correspond,  as  closely 
as  possible,  to  the  definition  of  tuc  language  in 
MIL- STD- 1 589A. 


A 


1 1  Hequi remen t s  Def ini tion 


In  recent  years,  Che  high  costs  of  software  development 
have  increased  Che  importance  of  the  use  of  software 
development  tools.  Currently,  the  L'S/eF  nas  a  considerable 
investment  in  major  software  systems  that  are  bei;\: 
developed  with  J73.  With  the  introduction  of  Ada,  which  i> 
supposed  to  replace  J73  as  the  USAF’s  approved  programming 
language  for  embedded  computer  systems,  it  has  oecom.e 
evident  that  an  automated  translation  system  from  to  Ad. 

is  needed  . 

The  Air  Force  Wright  Aeronautical  Labora tor ies/ Avion; c s 
Laboratory  has  stated  a  requirement  for  Che  development  ->! 
such  a  system.  Although  the  general  require::...:;:  •>: 

translation  is  rather  straightforward,  it  is  no  simple  . 

As  pointed  out  in  the  development  of  the  Autopsy  project  at 
the  University  of  Southern  California,  "there  are  cw 
constraints  guiding  the  deve Lopmen t  of  a  useful  translation 
system ; 

1.  A  translation  system  must  do  almost  all  of  tne 
work . 

2.  No  translation  system  can  do  all  of  the  work" 

(Ref  2:118). 

Invariably  there  will  be  sections  of  code  which  cannot  be 
directly  translated  because  of  unique  system  dependencies. 
In  such  cases  it  is  very  difficult  to  insure  the  correctness 
of  the  translation  and  the  user  must  perform  the  translation 
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manual ly . 


The  general  requirement:  can  be  divided  into  thr«j«. 
specific  parts.  First,  the  translation  system  should  acci.  : 
any  correct  J73  program  and  produce,  to  the  extent  possible, 
an  equivalent  Ada  program.  The  assumption  that  the  input  i - 
syntactically  correct  will  allow  for  the  elimination  of 
lengthy  error  detection  and  recovery  routines.  Secondly, 
when  a  direct  translation  is  not  possible,  the  translator 
should  identify  the  untranslated  code  to  allow  the  user  to 
perform  a  manual  translation.  Thirdly,  to  insure 

portability  of  the  translation  system,  its  design  snuaid 
conform  to  MIL- STD- 1 5£yA,  which  defines  the  syntax  and 
semantics  of  J7 3  . 

Since  J73  is  still  undergoing  changes,  the  syste 
should  be  designed  to  allow  modification  of  the  system  m> 
meet  the  changing  lan0uage  environment.  Since  the  scope  of 
this  research  project  was  limited  to  translating  a  subset  of 
J73,  the  system  snould  also  be  designed  to  facilitate  tne 
addition  of  the  remaining  translation  routines  to  complete 
the  translation  system. 

In  summary,  JATS  should  translate  J73  source  programs 
into  Ada  source  programs,  identifying  those  segments  of  code 
that  have  not  been  translated.  JATS  should  also  be  designed 
to  allow  maximum  portability,  meet  changing  langauue 
requirements,  and  allow  completion  of  the  translation 
process . 


The  analysis  of  any  large  software  project  is  an 
important  task  that  should  not  be  overlooked.  One  of  tk«. 
goals  of  any  system  analysis  should  be  to  identify  a] 1 
software  development  tools  that  may  be  applicable  to  thi 
project.  With  increased  emphasis  on  reducing  software 
development  costs,  the  use  of  available  software  that  has 
been  tested  and  implemented  must  be  considered  and  can 
reduce  the  overall  effort  and  therefore  tne  costs  of 
development  project.  This  is  especially  important  in  a 
research  project  which  must  be  limited  in  scope  in  order  to 
achieve  a  reasonable  goal. 

Translation  of  the  entire  J73  language  was  not  possible 
within  the  time  constraints  of  this  project.  Therefore  a 
subset  of  the  J73  language  was  selected  for  translation. 
This  subset  was  chosen  based  upon  the  nore  commonly  used 
features  of  the  language  so  that  the  results  would  be 
applicable  over  as  large  a  range  as  possible. 

Although  the  project  was  limited  to  translating  a 


subset 

of  J73  , 

the  de 

sign 

of 

the 

system  proci 

eeded  as  if 

tin. 

entire 

J73  language 

was 

to 

be 

translated  . 

This  will  a 

llow 

the  add 

ition  of 

the 

remaining 

translation 

routines 

wi  th 

minimum 

i  impact 

on 

the 

rest 

of 

the  system. 

Therefore , 

the 

design 

of  the 

front 

end 

of 

the  translator  system, 

the 

parser , 

was  a 

cri t ical 

part 

of 

the  project 

.  There  are 

two 

general  techniques  used  in  the  development  of  parsers. 


One 


is  the  use  of  top-down  recursive  descent  parsers  and  t:.^ 
other  employs  table-driven  bottom-up  parsers.  The  first 
technique  implements  the  parsing  algorithm  as  recursive 
procedures  whose  algorithms  depend  upon  the  language  to  be 
processed.  As  a  result,  a  general  parser  tor  more  than  one 
language  cannot  be  developed  since  the  parsing  algorithms 
will  change  from  one  language  to  another.  In  contrast,  tne 
second  technique  uses  algorithms  that  are  language 
independent  to  generate  and  then  use  a  set  of  parser  tables. 
Since,  the  tables  contain  the  specific  information  about  tne 
language,  the  algorithms  can  be  implemented  to  generate 
parsers  for  any  members  of  a  given  family  of  languages.  Tne 
particular  family  of  lan0uages  depends  upon  the  algori  tn 
used  to  generate  the  parser.  One  such  parser  generator 
package  is  ”LR:  Automatic  Parser  Generator  and  LR(1)  Parser''' 
designed  at  Lawrence  Livermore  National  Laboratory  (LLNL) 
(Ref  1 2) . 

LK  Parser  Generator 

The  LR  package  is  a  set  of  programs  written  in  A.'L  l 
standard  FORTRAN  66  which  have  been  successfully  used  in 
many  applications.  The  package  is  currently  available  on 
the  Aeronautical  Systems  Division's  Control  Data  Corporation 
CYBER  175  computer  system  and  has  been  use„  in  previous  AF1T 
research  efforts.  The  AFWAL/AA  DecSystem-1 0  computer  system 
can  also  support  LR.  The  first  program  of  the  LR  package, 
LRS ,  is  the  table  generator.  It  is  complete  in  itself  but 
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has  Cwo  implementation  dependent  subroutines  tnat  rt^uiri 
minor  changes  to  implement  it  on  the  DecSysten- 1 0 .  Tin 
second  program,  PKS,  is  the  parser  skeleton  and  must  Ik 
supplied  with  the  necessary  support  routine  to  complete  tn«. 
language  processor.  These  required  routines  are  the  lexical 
processor,  which  recognizes  the  lexical  elements  of  t:u 
language,  and  the  semantic  processor,  which  defines  the 
semantics  of  the  language  processin0. 

Since  both  parsing  techniques  require  tne  lexical  and 
semantic  processors,  the  two  techniques  do  not  differ  in 
that  aspect.  However,  since  a  parser  generator  package 
available,  the  table-driven  bottom-up  parser  «xs  chosen  for 
this  research  project. 

Decisions 

Since  LR  was  available  for  use  in  the  development  ol  i 
translator  system,  the  major  decision  tli.it  ha  l  to  be  m  ■  :< 

before  development  could  proceed  was  the  choice  of  a 

programming  language.  Since  LK  was  written  in  ANSI  standard 
FORTRAN  66,  the  continued  use  of  FORTRAN  was  possible,  but 
undesireable .  The  main  reason  for  this  was  tne  anticipated 
use  of  various  data  structures  and  recursive  al0orithms 
which  cannot  be  implemented  in  FORTRAN.  Also,  one  of  the 
goals  of  the  Ada  support  environment  is  to  develop  the 

software  tools  using  Ada.  Therefore,  Ada  would  have  been 

the  obvious  choice.  However,  the  lack  of  a  compiler  would 


9 
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have  seriously  restricted  the  development  and  testin0  or  tne 
system.  The  next  choice  was  J73,  which  was  an  excellent, 
choice  for  several  reasons.  J73  is  a  block  structured 
programming  language  which  allows  the  use  of  structured 
programming  techniques  and  any  system  that  supports  J73  * 
should  also  be  able  to  support  the  translator  system. 
Another  possible  reason  might  be  the  fact  that  the 
translator  could  then  translate  itself  into  an  Ada  version. 
However,  this  approach  would  not  be  equivalent  to  developing 
the  translator  in  Ada. 

There  was  only  one  drawback  to  designing  the  translator 
system  in  another  language;  the  parser  skeleton,  PRS,  was 
written  in  FORTRAN.  However,  this  was  a  minor  drawback 
since  the  parser  skeleton  was  also  available  in  a  PASCAL 
version  as  a  result  of  an  AFLT  class  project  for  the 
Advanced  Compiler  Tneory  course.  Since  the  algorithms  used 
in  the  parser  skeleton  are  short  and  straightforward,  and 
were  already  implemented  in  a  block  structured  programming 
language,  the  process  of  translating  the  parser  skeleton 
into  J73  did  not  involve  much  effort. 
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IV  System  Sof tware  Development 

The  bulk  of  this  research  project  was  the  development 
of  the  Jovial(J73)  to  Ada  Translation  System  (JATS) 
software.  JATS  consists  of  three  functional  module-;: 
(1 )  parser  module,  (2)  translation  module,  and  (3) 
prettyprint  module.  The  parser  module  was  developed  using 
the  LLNL  parser  generator  package  and  produces  a  parse  tree 
of  the  source  program.  The  translation  module  uses  the 
parse  tree  and  performs  a  direct  translation  of  the  nodes  of 
the  tree.  The  result  of  the  translation  is  a  modified  parse 
tree  which  represents  an  equivalent  Ada  program.  The 
prettyprint  module  uses  the  modified  parse  tree  to  build  a 
formatted  text  fiLe  whicn  contains  the  Ada  program.  Each 
module  of  the  system  wilL  be  described  in  detail. 

Parser  Module 

The  parser  module  implements  a  table-driven  bottom-up 
parser  designed  using  the  LR  parser  generator.  Lk  is  a 
language  processing  tool  consisting  of  two  programs.  The 
first  program,  LRS ,  is  an  automatic  parser  table  generator. 
The  second  program,  PRS,  is  a  parser  skeleton.  When  the 
tables  from  LRS,  the  lexical  processor,  and  the  semantic 
processor  are  added  to  PRS  the  result  is  an  LR(1)  parser  and 
language  processor.  The  LR(1)  characteristic  of  the 
language  is  a  design  constraint  of  the 
the  syntactic  type  of  the  language 
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grammar  which  defines 
and  means  that  the 


language  can  be  parsed  from  lef C- co-right  with  a  lookahead 
requirement  of  one  symbol.  A  language  of  this  type  can  be 
recognized  by  a  deterministic  pushdown  automaton  in  linear 
time  (Ref  7:501).  A  deterministic  pushdown  automaton  uses  a 
stack  and  the  knowledge  of  the  current  state  and  lookahead, 
symbol  to  decide  the  next  course  of  action.  The  parser 
tables  from  LRS  provide  the  control  information  for  the 
finite  state  automaton  while  PRS  provides  the  definition  of 
the  process.  The  design  of  the  parser  module  involved  four 
major  phases:  (1)  parser  table  generation,  (2)  parser  table 
translation,  (3)  parser  implementation,  and  (h)  semantic 
processing.  Each  of  these  sections  will  be  discussed  in 
further  detail  . 

Parser  Table  Generation .  LKS  accepts  an  LR(1)  grammar 
in  a  modified  Backus-Naur  Form  and  produces  a  grammar 
analysis  and  a  set  of  parser  tables.  However,  some  work  was 
necessary  to  implement  LRS  on  the  DecSv s ten- 1 0 .  Lkh 
contains  two  subroutines  that  are  implementation  dependent  , 
INIT  and  CHKIND.  I NIT  initializes  the  input  and  output 
files.  CHKIND  converts  a  single  character  stored 
lef t-justif ied  in  one  word  into  an  integer,  the  character 
code,  and  required  the  use  of  a  macro  subroutine.  This 
macro  routine  is  a  function  called  ICHK.  With  these  two 
changes,  LRS  was  successfully  running  on  the  DecSy s tern- 1 0 . 
Also,  before  LRS  would  process  the  complete  J73  grammar, 
several  other  changes  had  to  be  made  within  it.  Considering 
the  size  of  LRS,  this  was  no  minor  task.  These  changes 
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involved  increasing  the  sizes  of  some  of  the  dimensioned 
variables  to  accommodate  the  large  grammar.  These  changes 
are  discussed  in  greater  detail  in  Appendix  A. 

One  other  change  was  made  to  enhance  the  use  of  LRS  . 
In  the  version  available  at  AF1T,  both  the  grammar  analysis 
and  the  parser  tables  were  output  to  the  same  file  and  the 
parser  tables  had  to  be  copied  to  another  file  with  the  use 
of  an  editor  program.  The  grammar  analysis  consists  of 
large  amounts  of  data  describing  the  parser  and  is  usually 
output  to  the  printer  while  the  data  tables  are  placed  into 
a  data  file  to  be  inserted  into  the  parser  skeleton.  To 
separate  these  output  files,  one  additional  output 
subroutine  was  added  to  write  the  data  tables  to  a  different 
file.  A  description  of  this  subroutine  is  contained  in 
Appendix  A. 

The  J73  grammar  is  input  to  LRS  in  a  modified 
Backus-Naur  Form,  which  is  a  convenient  way  of  describing 
the  syntax  of  programming  languages.  Several  problems  were 
encountered  during  this  pnase  of  the  project  since  a 
complete  LR(1)  grammar  was  not  available.  After 
considerable  effort  to  rewrite  the  grammar  from 
MIL-STD-1  589A  into  a  form  that  was  LR(1),  an  LR(1)  grammar 
for  the  executable  statements  of  J73  was  obtained  fro:.. 
Softech  Incorporated  (Ref  8).  However,  the  remaining  grammar 
for  the  declarations  was  not  LR(1).  According  to  Softech 
Inc.,  they  developed  the  J73  compiler  using  a  top-down 
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recursive  descent  parser  for  the  declarations  and  a 
table-driven  bottom-up  parser  for  the  statements  and 
therefore  did  not  have  a  complete  LK(1)  grammar  available. 
However,  according  to  the  language  designers  at  Softer. : 
Inc.,  J73  is  a  deterministic  context  free  language,  which 
implies  (Ref  7:512)  that  an  LR(1)  grammar  does  exist  for  tnu 
language.  Rewriting  the  grammar  was  no  minor  tasK  and  there 
are  still  several  places  in  the  grammar  where  the  translator 
will  not  accept  a  syntactically  correct  J73  program..  Tue 
resulting  grammar  is  contained  in  Appendix  B.  The  greatest 
discrepancy  is  probably  the  complete  lac'.;  of  a 
<block-preset>  definition.  The  definitions  of  the 
<block-prese t>  and  the  <table-prese t>  conflicted,  resulting 
in  a  grammar  that  was  not  LR(1 ) .  The  grammar  for  the 
<block-preset>  could  have  been  rewritten  but  would  have  been 
a  time  consuming  process.  The  <block-preset>  was  eliminated 
in  favor  of  allowing  development  to  proceed  on  the  remaining, 
modules  of  the  system.  However,  use  of  the  <block-pres<_  t  > 
does  not  appear  to  be  that  extensive  and  this  loss  of 
completeness  was  assumed  to  be  justified.  Other 
discrepancies  are  concerned  with  some  of  the  si.’.e 
constraints  in  some  of  the  data  declarations.  The  problem 
was  that  the  <formula>  in  some  of  these  cases  was 
immediately  followed  by  a  left  parenthesis  -while  the  grammar 
for  a  subscripted  variable  can  be  a  <name>  followed  by  a 
left  parenthesis.  For  a  grammar  to  be  LR(1),  the  parser  has 
to  be  able  to  decide  what  to  do  in  its  present  state  based 
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upon  the  next  token,  or  symbol,  of  tne  input  stru.  . 
However,  with  this  conflict,  the  parser  could  not  decide 
whether  to  combine  the  <name>  and  left  parenthesis  to 
generate  the  subscripted  variable  or  reduce  the  <name>  to  .4 
<formula>  to  generate,  for  example,  a  <status-size> .  The  » 
specific  areas  that  are  constrained  are  the  <status-size>  in 
the  declaration  of  a  status  item,  the  <bi ts-per-en try>  and 
<entry-size>  in  the  declaration  of  structured  tables,  one. 
the  <repetition-count>  in  a  <table-preset> .  Again,  these 
constraints  do  not  appear  to  place  a  serious  limitation  upon 
J73  users.  These  discrepancies  are  summarized  in  table  1. 


MIL-STD-1 589A 
Reference 


Table  1 

Grammar  Discrepancies 
Element 


Current 

Definition 


2.1  .1  .6 

<status-size> 

<integer- 1 i Lera  1 > 

2.1  .2.2 

<b i t  s - p  e  r -entry) 

vintager- 1 i tera 1 > 
< named 

<f unction- cal  1 > 

2.1  .2.4 

<entry-size> 

<integer- 1 i tera i 0 
<name> 

<function-cal 1> 

2.1  .6 

<repetition-count> 

< integer- literal.  > 

2.1  .6 

<block-preset> 

Rot  Defined 

It  should  also  be  noted  that  a  <name>  which  has  not  yet 
been  defined  during  parsing  of  declarations  is  scanned  as  a 
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<name>  while  an  undefined  <name>  during  pars i ng 
statements  is  scanned  as  a  <proc- label-name> .  I 

distinction  was  necessary  in  the  grammar  definition  to  n. 
it  LK(1  )  . 

Once  an  LR(1)  grammar  for  J73  was  defined,  LK5  prode 
a  valid  set  of  parser  tables.  The  J7d  grammar  that  was  u 
to  generate  these  parser  tables  is  contained  in  Appendix 
The  specific  contents  and  structure  of  the  tables 
described  in  Appendix  A. 

Parser  Table  Translation .  Once  the  parser  titles 
obtained  from  LKS ,  a  translation  step  v;«  s  required 
transform  the  data  tables  into  the  J7i  language  in  a  f 
that  was  equivalent  to  the  FORTRAN  6b  DINhN.'loN  and  1 
statements.  The  data  tables  were  processed  by  TAbd: . 
and  produced  J73  constant  table  declarations  that  dupl ica 
the  FORTRAN  60  data  structures.  These  statements  we  re  t 
collected  together  as  a  eonpoo  1  nodule.  J?  j  c  or.poe ;  r.odu 
are  separately  compilable  modules  th..t  eon  tain.  d 
declarations.  The  use  of  the  compool  mod ule  proved  t. 
very  advantageous  since  tne  tables  were  very  lai\  e 
required  about  five  minutes  of  cpu  time  for  compilation 
the  DecSy s ten- 1 0 .  The  J7d  compool  module  provided 

parser  table  information  for  the  parser  skeleton. 

Parser  Xmplementat  ion .  PKS  provided  a  FORTRAN’  par 
skeleton  which  had  to  be  translated  into  J 7 J .  This  step 
relatively  simple  since  PRF  nad  already  been  translated 
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PASCAL  and  the  same  data  structures  were  available  in 
Four  subroutines  make  up  the  main  parsing  algoritn 
(1)  FIND ' REDUCTion ,  (2)  FIND ’ TKANs i t ion ,  (3)  DO’ REDUCE io 

and  (4)  DO’ TRANsition .  FIND’ REDUCT  uses  the  current  st.-. 
and  token  to  search  the  tables  for  a  possible  reduction, 
one  is  found,  the  applicable  language  production  is  used 
DO’ REDUCT  to  call  the  semantic  processor  and  reduce  t 
information  in  the  stacks  aecordin '.lv .  If  a  reduction 
not  possible  from  the  current  state,  FIND'TkrtN  so  itches 
tables  for  a  possible  transition  to  another  state, 
transition  is  possible,  DO'  TRAN  stacks  the  curr.: 
information  on  the  appropriate  stacks  and  calls  the  1  o  x :  c 
processor  for  the  next  token  in  the  input  stream, 
neither  a  reduction  nor  transition  is  possible,  the  pac¬ 
has  detected  an  error  and  must  recover.  Since  th 
translator  was  designed  with  the  assumption  that  the  inp 
programs  are  correct,  any  errors  detected  will  result  :  - 
grammar  discrepancies  and  mat  part  of  t.ie  progr  v.  cani-t 
processed  . 

The  major  addition  to  the  skeleton  to  complete  r. 
parser  was  the  lexical  processor  or  scanner.  To 

subroutine  performs  a  lexical  analysis  of  the  input  a 
supplies  the  parser  with  the  tokens  of  the  input  str<_-a 
For  example,  the  assignment  statement  in  figure  1  consis 
of  three  lexical  elements:  (1)  TEST' FLAG  which  is  a  J 
identifier  or  <name>,  (2)  the  equal  sign,  and  (3)  t 
reserved  word  FALSE.  The  lexical  structure  differs  fro",  u 
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TEST' FLAG  =  FALSE 


Fi0  1.  Assignment  Statement 

language  to  another  implying  the  need  for  a  specialised 
scanner.  The  lexical  elements  of  G7o  consist  e: : 
(1)  reserved  words  and  symbols,  (2)  identifiers  or  <aa~i ><  , 
(3)  numbers,  (4)  character  strings  or  <charact  er-li  tcr.:l  s'- , 
(5)  directives,  and  (6)  comments.  Procedures  that  are  : 
to  the  lexical  processor  are  uses  to  sc. a-,  the  ditferea; 
elements  of  the  language .  These  procedures  as  av  1 1 
several  functions  whicn  support  the  lexical  processor  u:\ 
described  in  Appendix  C. 

Semantic  Processia,, .  Tne  semantic  processor  describe 
the  actual  language  processing.  Wiinout  the  semarr.  :  c 
processor,  the  parser  is  complete  in  that  it  will  recogai.e 
the  grammar.  However,  for  a  language  processor  to  perform 
useful  function,  the  definition  of  the  semantic  process  must 
be  provided.  Tnese  routines  are  very  dependent  on  the 
source  language  and  the  purpose  of  the  langua0e  processor. 
For  example,  the  semantic  processor  of  a  compiler  typically 
contains  the  symbol  table  manipulator  and  code  generator. 
However,  for  a  translator,  the  semantic  processor  needs  to 
preserve  the  structure  of  the  source  program  until  it  has 
been  completely  parsed,  at  which  time  translation  can 
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proceed.  The  data  structure  that  was  selected  to  represent 
the  program  was  the  parse  tree.  An  example  of  a  partial 
parse  tree  of  the  assignment  statement  from  figure  1  is 
shown  in  figure  2.  Tne  labels  on  the  links  in  figure  2  will 
be  discussed  in  the  next  paragraph. 


The  reason  that  this  structure  was  selected  ms  bee  »,:sc  i* 
records  the  complete  parse  of  the  source  progr  and  al  low- 
further  processing  on  an  element -by-element  b  -.sis. 

The  specific  data  structure  that  was  selected  t  > 
represent  the  parse  tree  was  a  linked,  list.  The  node  while  i 
represents  the  assignment  statement  in  figure  2  would 
consist  of  four  list  elements,  one  describing  the  node  and 
three  identifying  the  subtrees  of  the  node,  and  is  shown  in 
figure  3.  This  is  accomplished  by  using  four  identical 
elements  each  containing  the  three  following  fields: 
(1 )  NODE'PTR  which  is  an  integer  field,  (2)  LINK'TYPE  which 
is  an  integer  field,  and  (3)  NODE' LINK  which  is  a  pointer 
field  containing  an  absolute  machine  address.  The  contents 
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Fig  3.  <assignment-stmt>  Node 


of  NODE'PTR  of  the  first  element  of  the  linked  list 
representation  of  a  parse  tree  node  contains  the  production 
number,  or  language  rul*  _hat  was  used  to  obtain  the  node 
from  its  subtrees.  NODE'PIK  of  all  other  elements  of  a  node 
contain  the  node  number  which  identifies  the  subtrees.  The 
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valuto  contained  in  NODE'PTK  of  these  remaining  elements 
correspond  to  the  links  shown  in  figure  1.  LINK ' TYPE  =  C 
for  all  elements  of  an  internal  node  of  the  tree  and 
indicate  that  NODE'LINK  points  to  the  next  element  of  the 
node.  The  final  element  of  a  node  will  have  a  NODE'LIN:.  . 
that  has  a  null  value.  Using  this  structure  to  describe 
node  within  tne  tree,  the  nodes  of  various  sizes  can  be 
efficiently  stored  without  wasted  space,  a  very  important 
consideration  in  such  a  large  software  project.  Thi 

structure  also  allows  for  the  dynamic  nature  of  tne  tin, 
during  the  translation  process. 

If  the  node  is  a  terminal  node,  a  leaf  of  the  tret  , 
then  the  value  of  LINK' TYPE  will  be  non-zero  and  tin.  otn  r 
fields  will  have  other  meanings.  For  all  terminal  node.  , 
NODE'PTK  will  contain  the  token  number  of  the  tormina’, 

symbol.  If  the  terminal  node  is  a  reserved  word  or  symbol , 
LINK 'TYPE  will  have  the  value  3,  and  NODE'LINK  will  have  a 
null  value.  If  the  terminal  node  is  a  <namo>  or 

<charac ter- li teral> ,  LINK'TYPE  will  have  the  value  3,  but 

NODE'LINK  will  point  to  another  element  which  will  be 

interpreted  as  follows.  If  the  node  is  a  <name>, 
NODE'PTK  =  0,  LINK’TYPE  =  3,  and  NODE'LINK  points  to  the 
symbol  table  entry  for  the  <name>.  If  the  node  is  a 
<character- literal> ,  NODE'PTK  contains  the  index  into  the 
string  table  to  identify  the  string,  LINK'TYPE  =  3,  and 
NODE'LINK  has  a  null  value. 


-A 


21 


If  terminal  node  is  an  integer-literal  >, 

LINK'TYPE  =  1,  and  NODE'LINK  points  to  an  element  that 
contains  the  integer  value  of  the  node.  If  the  termini 
node  is  a  <real-literal> ,  LINK ' TYPE  =2,  and  NODE ' LI NK 
points  to  an  element  that  contains  the  real  value  of  the 
node . 


The  parse  tree  is  a  collection  of  these  nodes,  sucn 
that  the  root  of  the  parse  tree  is  the  <complete-pr ogra: 
and  NODE(I)  contains  a  pointer  to  the  first  element  of  tile 
I  th  node.  J73  has  pointer  variables  whicn  can  be  easily 
manipulated  to  implement  a  linked  list  strut  tare;  however, 
the  current  compiler  does  not  yet  support  execution  time  or 
dynamic  allocation  of  memory.  Tnerefore,  it  was  necessary 
to  declare  a  HEAP,  or  large  storage  space,  which  can  be  use.: 
to  store  these  dynamic  elements.  In  order  to  make  efficient 
use  of  such  a  neap,  a  dynamic  allocation  algor  1 1  !r  , 
implemented  as  a  function  KELP,  is  used  to  cont  r  i 

allocation  of  new  elements.  Durin0  the  parsing  process  i;.>. 
parse  tree  is  continually  growin0  and  deallocation  e>:  um  .. 
heap  space  does  not  occur.  Tnerefore,  NEXT1  NUDE,  wnicti  i a 
the  index  of  the  next  available  NODL,  needs  only  to  be 
incremented  by  one  each  time  a  node  is  allocated.  Likewise, 
NEXT'HEAP,  which  is  the  pointer  address  of  the  next 
available  heap  space,  needs  only  to  be  incremented  by  the 
size  of  the  space  to  be  allocated.  Additional  routines  and 
data  structures  to  implement  the  allocation  algorithms  will 
be  covered  during  the  discussion  of  the  translation  module. 
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The  heap  is  also  used  lor  storage  of  the  symbol  table . 
For  a  translation  system,  the  entire  symbol  table  must  be 

kept  until  the  translated  program  can  be  output  since  tn>. 

terminal  nodes  simply  contain  a  pointer  into  the  symbol 
table  to  identify  the  <name>  of  the  node.  This  is 

contrasted  to  the  maintenance  of  the  symbol  table  in  a  o:n 
pass  compiler  where  the  symbol  table  entries  for  a  give:: 
lexical  level  can  be  deleted  when  that  lexical  level  i- 
exited.  The  symbol  table  is  stored  as  a  hash-code  i 
collection  of  separate  chains  (Ref  10:513)  where-  HEAL' ( 1  ) 
contains  a  pointer  to  the  first  symbol  table  entry  in  t'.« 
1th  chain.  Lacn  element  of  the  symbol  table  contains  live 
fields:  (1)  SY.'d  ’  S  1'0rE '  P I  k  which  is  the  index  into  t  a 

character  storage  array  for  tin.  first  character  of  tae 

symbol,  (2)  SYMBOL '  LENGTH  whicn  is  the  nu~bcr  of  char  ..‘hr.- 
in  the  symbol,  (3)  SYA'LINK  which  contains  a  pointer  to  thi 
next  element  of  tiK  chain,  (4)  TYPE*  CLASS  which  is  used  •. 
define  the  class  of  the  symbol,  and  (3;  PKOC'Nl'b.  wi.icn 
indicates  which  procedure  the  symbol  was  declared  in.  T re- 
possible  type  classes  are  listed  in  table  II  and  are  use1, 
during  the  parsing  process  to  return  the  proper  token  symbol 
from  the  lexical  scanner.  PROC 1  Rid  1  is  used  to  allow  tile 

same  <name>  to  be  used  at  different  lexical  levels.  Another 
array,  PARENT ’ PKOC ,  is  used  to  identify  the  nesting  of  the 
procedures  . 

Symbol  table  entries  are  made  by  the  scanni.i,, 
procedures  at  the  time  that  the  symbol  is  first  scanned  in 
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TABLE  II 


Type  Classes 

Value  Classification 


0  <name> 

1  <i tem- type*name> 

2  <table- type-nane> 

3  <block- type-nam.e> 

4  <proc-name> 

3  <label-nar.ie> 

6  <def  ine-nar:ie> 

7  <proc-label-name> 


procedure  NAME '  KESWOKD .  Tne  scanner  also  ouilds  tne 
terminal  nodes  of  the  parse  tree  and  provides  the  number  u: 
the  node  to  the  semantic  processor  lor  the  semantic  stave. 
The  remainder  of  the  semantic  processing  is  accomplished  in 
procedure  SEMANTIC,  which  is  called  from  DO’KEDL'CT  when  a 
reduction  is  to  take  place.  Tne  semantic  stack  will  contain, 
the  node  numbers  of  each  of  the  subtrees  of  the  current 
production,  or  rule,  that  is  to  be  reduced.  The  semantic 
process  consists  of  buildin0  a  new  node  which  combines  tb<. 
subtrees  of  the  production.  For  example,  tne  production 
used  to  build  the  assignment  statement  is  shown  in  figure  4. 


<assignment- s tmt>  :  :  =  < targe t- 1  i s t>  =  Expression/ 


Fig  4.  Assignment  Statement  Production 


When  SEMANTIC  is  called,  the  number  of  this  production  is 
passed  as  a  parameter  and  the  new  node  is  built  from  the 
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semantic  stack.  The  elements  on  the  right  hand  side  o:  l:h- 
production  are  at  the  top  of  the  stack  and  are  used 
construct  a  new  node  as  follows:  (1)  the  production  number 
is  used  to  construct  the  first  element  of  the  new  node, 
(2)  the  last  element  of  the  node  is  on  top  of  the  stacK  and 
is  added  to  the  node  by  creating  a  new  element  and  linKin^, 
it  to  the  first  element.  The  process  of  poppinc  the  t 
element  from  the  stack  and  inserting  it  after  the  lirs: 
element  of  the  new  node  is  repeated  until  tne  complete  nod., 
has  been  constructed.  The  reduction  process  then  pushes  t 
new  lefthand  side  of  the  production  and  the  new  node  tium 
was  just  constructed  onto  the  stacks. 

The  semantic  routines  also  add  information  to  t;,«. 
symbol  table  when  a  declaration  is  processed  to  establish 
the  class  of  the  symbol  table  entry.  For  example  ,  t:.<. 
production  in  fi0ure  5  would  cause  the  symbol  table  entr_. 
for  <name>  to  bo  set  to  indicate-  that  the  entry  is  ;  . 
< item- type-namc>. 


<i tem- type-dec>  : :=  TYPE  <name>  <i tern- type-desc rip t ion >  ; 

Fig  5.  Declaration  of  Item  Type 

The  sane  actions  would  apply  for  processing  of  blocx 
declarations,  procedure  declarations,  label  declarations, 
table  declarations,  and  define  declarations. 
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When  Che  parsing  module  has  comp ics  ^rocessin0 
the  parse  tree  and  the  symbol  table  will  have  been 
constructed  to  allow  the  translation  process  to  begin. 

Translation  Module 

Translation  of  the  J73  program  is  accomplished  in  twu 
separate  steps.  The  symbol  table  is  processed  lir.'.i 
followed  by  the  processing  of  the  parse  tree.  Process  i:^  o: 
tne  symbol  table  translates  J73  identifiers  into  Ad., 
identifers.  The  identifiers  of  both  lan0uuges  consist 
primarily  of  letters  and  dibits.  The  only  differences 
between  the  identifiers  is  the  use  of  the  dollar  si0n  and 
the  single  quote  in  J73  and  the  use  of  the  underscore  in 
Ada.  The  dollar  sibn  is  used  to  represent  special 
characters  that  may  be  required  in  external  names  and  is 
implementation  defined.  Ada  has  no  equivalent  structure; 
therefore,  the  dollar  sign  is  not  translatable  and  is  not 
allowed  in  programs  to  be  translated.  The  use  of  the  .17  J 
single  quote  is  similar  to  the  use  of  the  underscore  in  Ad,; 
but  J73  allows  a  more  liberal  use  of  the  single  quote. 
After  surveying  the  programmers  who  use  J73,  it  was  found 
that  the  most  common  usage  of  the  single  quote  was  as  a 
seperator  between  parts  of  an  identifier.  Such  usa^e 
conforms  to  the  rules  of  the  use  of  the  underscore  in  Ada 
and  the  translator  was  therefore  designed  with  the 
requirement  that  the  use  of  the  single  quote  conform,  to  the 
rules  of  the  use  of  the  underscore  in  Ada.  One  other 
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assumption  was  made  to  preclude  the  requirement  JAit 

generate  new  identifiers:  J73  identifiers  will  not  consis: 
of  Ada  reserved  words.  This  greatly  simplified  t:u 
translation  of  identifiers  since  all  that  is  now  required  i 
changing  all  single  quotes  into  underscores  during  a  sin0i«. 
pass  through  the  symbol  table  character  strinc  stora0e. 
Processing  of  the  symbol  table  in  this  manner  results  in 
each  identifier  being  translated  exactly  once  instead  e: 
processing  an  identifier  each  time  that  it  j.o  found  in  t.u- 
parse  tree.  If  JATS  was  an  interactive  system,  the  above 
limitations  could  be  removed  since  JATS  could  request 
assistance  from  the  user  to  rename  any  identifier  t':u,t  w\. 
found  to  not  conform  to  tne  rules  of  Ad.;. 

The  remainder  of  the  translation  process  consists  o: 
manipulation  of  the  parse  tree  by  procedure-  TnAASLAl . 
Translation  of  the  terminal  nodes,  or  leaves,  is  not 

required  since  the  translation  of  identifiers  nas  al  re..  :y 

been  accomplished  and  blariKct  translati or,  of  reserved  war... 
and  symbols  is  not  performed.  The  translation  process  is 
language  production  oriented,  that  is,  each  node  i 

processed  based  on  the  production  number  that  was  used  to 

construct  the  node.  The  tree  is  processed  m  a  bottom  up 
fashion,  with  each  subtree  of  a  given  node  being  processed 
before  the  node  itself  will  be  processed.  Recall  that  the 
first  element  of  each  internal  node  contains  the  production 
number  for  the  node  and  this  is  used  to  select  the 
appropriate  action  through  a  case  statement.  Each  Idnyj.y^- 
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production  will  have  a  case  alternative  that  define.-  :..L 
specific  actions,  possibly  none,  that  take  place  Jur::. 
translation  of  a  node  that  was  constructed  witn  t:.-. 
production.  There  are  four  basic  processes  that 
performed  during  transla tion :  (1)  changing  reserved  word, 

and  symbols,  (2)  adding  new  terminal  symbols,  (3)  deleting 
existing  elements,  and  (4)  rearranging  the  elements  of  t.n 
node.  Each  of  these  operations  will  be  discussed  further. 

The  process  of  changing,  a  reserved  word  or  symbol  i  s 
simple  given  the  structure  ot  the  parse  tree.  Once  t  •••. 
proper  element  of  the  node  is  identified  by  u  point  e  r 


variaole , 

NODE'PTK 

of 

tnat  el  erne: 

it  identifies 

Luc  IcT’v.i 

node  that 

contains 

tne 

r  e  s  e  r  v  e-  4 

wo  r  2  or  s v 

mivl.  1  lit 

NODE'  PTR  of  this  terminal  node  contains  tne  Loiter,  nutter 
that  identifies  the  reserved  word  or  symbol.  The  process  ot 
changing  the  reserved  word  or  symbol  then  simply  require 
changing  the  value  of  NoDL'PTk  at  tne  terminal  node.  1  .e 
process  of  changin0  a  symbol  or  reserved  word  is  per  for-  e  d 
by  procedure  CHANGE’ NUDE.  The  translation  process  of  the 
assignment  statement  from  figure  2  is  shown  in  figure  6. 
When  the  node  that  represents  the  <ass ignmen t- s tm t >  is 
translated,  a  pointer  variable,  N'PTK,  is  updated  to 
identify  the  second  element  of  the  node.  NODE'PTK  at  this 
element  identifies  the  node  that  represents  the  equal  sign. 
The  value  of  NODE'PTK  for  the  equal  sign  is  48  and  i- 
changed  to  a  value  of  171  to  represent  the  assignment 
operator  of  Ada. 
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The  process  of  adding  a  new  terminal  symbol  to  the 
production  is  a  little  more  difficult.  It  involves  creating 
a  new  node  and  inserting  a  new  element  in  the  chain  o: 
elements  which  makes  up  the  node.  This  requires  that  Lice 
position  of  the  new  element  be  identified  and  the  new 
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terminal  symbol  be  specified.  Once  the  element  tn^t  .. .  .  . 
preceed  the  new  element  has  been  identified,  procedu: « 
ADD' NODE  will  create  a  new  node  that  represents  the  :n  . 
terminal  symbol  and  establish  the  necessary  links.  I:..- 

process  is  shown  in  figure  7  for  the  translation  o: 
<label>  where  a  new  symbol,  << ,  must  be  added  Delore  t  .■ 
<proc- labe l-name>  and  the  colon  follow!:.  :  :.e 

<proc- labe l-name>  is  changed  to  >>. 
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T'nc  process  of  deleting  an  element  of  a  node  is  r.;; 
simple,  just  relink  the  appropriate  elements  of  the  chain 
eliminate  the  desired  element.  However,  since  the  tree  i 
dynamic  structure,  the  utilization  of  the  heap  is 
efficient  when  some  type  of  storage  reclamation  is  perfor 
as  elements  of  the  tree  are  deleted.  Tnerefore, 

procedures,  DELETE' NODE  and  DELETE '  SL'bTEEE ,  are  used,  to  f 
heap  space  when  a  node  element  is  delete:  fro-:.  t:u  pu 
tree.  DELETE*  NODE  releases  trie  identified  element  :  rot. 
node's  chain  while  DELETE '  SI  ETnEE  releases  L.  Nd^Ls 
elements  of  the  subtree  that  were  deleted  as  a  resul t  of 
deletion  of  tne  initial  element .  However ,  som<.  cit^nj.e  > 
the  allocation  al cor i turns  w-.-re  reeutred  to  ir.pl  e- . 

reallocation  of  the  spate  collected  throuuk  star 

reclamation.  Usin0  an  over  1 a/e -  data  structure  each  n 
can  contain  either  a  pointer  value,  NODE  (I )  ,  to  a  node  c:. 
or  an  integer  value,  FklE  '  NODE  (I )  ,  which  indexes  the  n 
node  of  the  linaewi  list  ot  a  v  a  i.  x  a  o  ±.  e  ae.es.  .. 

NODE  (NEXT  '  NODE)  is  allocated,  FREE ' NODE ( NEXT '  NuLL ) 
a  link  to  the  next  available  node.  No  1 1  t;.,m  NEE  T ' 

cannot  simply  be  incremented  as  during  the  parsing  proves 

Storage  reclamation  of  the  released  node  elements 
accomplished  by  linking  the  elements  topetner  usinp 
already  available  pointer  field  NODE 'LINE.  If  a  list 
available  elements  exists,  FREE'PTk  is  a  pointer  to 
first  available  element  in  the  list  and  NODE' LINE 
FREE'PTK  is  a  link  to  the  next  available  element.  If 
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list  is  empty,  FREL'PTR  =  NULL,  and  allocatio: 
is  necessary  . 


1  ro::.  t:ie-  i;l.. 


Rearranging  the  elements  of  a  node  is  also  a  sit.pl>. 
operation  with  the  structure  of  the  parse  tree  an... 
corresponds  to  swapping  the  order  of  the  subtrees  of  a  node. 
Procedure  SWAP' NODES  is  used  to  swap  two  elements  trial  .»:n 
adjacent.  If  the  desired  elements  are  not  adjacent, 
repeated  swaps  must  be  performed  until  tne  desired  cnan. e  i 
achieved.  An  example  of  this  process  can  be  see:,  in  1 1 . e 
translation  of  a  <prograrr.-body>  using  production  nuv.bc  r  . 
The  structure  of  tne  parsed  node  is  snovn  in  figure  £>.>  and 
figure  Sb  shows  tne  results  after  swapping  tr.e  elements  t.i.;t 
correspond  to  the  nodes  defining  BEGIN  and  <dc c -  1 i s t G  . 


a.  BEGIN  <dec-list>  <stmt-list>  <sub-de :  -  1  i  s  •.  "v 

<direct-c  o:r.  pound- tr.  d  '• 

b.  <dec-list>  BEGIN  <stmt-list>  <sub- del -  1  is f > 

<direct- compound- end > 

c.  <dec-list>  BEGIN  <sub-def- list>  <stmt-list> 

<d irec t- compound- end  ’ 

d.  <dec-list>  <sub-def- list>  BEGIN  <stir.t-list> 

<d irec  t- compound  -  end  .> 


Fig  8.  Translation  of  <progran-body> 

Then  <stmt-list>  and  <sub-def- list>  are  swapped  resulting  in 
figure  8c.  Finally,  BEGIN  and  <sub-def-list>  are  swapped 
and  a  semicolon  is  added  as  the  last  element  of  the  node  t  ■ 
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compicr,  the  translation  as  shown  in  figure  So.  hole  t:. 
the  first  element  of  the  two  that  are  to  be  swapped  must 
identified  by  a  pointer  variable  each  time. 

One  other  procedure  is  used  during  the  translati 
process  to  simplify  the  actions  taking  place.  That 
procedure  MOVE '  PTk ,  which  simply  moves  tne  pointer  in  t 
node's  chain  of  elements  a  specified  number  of  elements. 

Most  of  the  language  productions  that  have  Re¬ 

translated  used  simple  additions,  deletions,  and  changes 
the  nodes.  However,  some  of  the  translations  required  ;  .> 
work.  One  example  is  tne  translation  ot  integer  it 
declarations  that  specified  the  <integer- s i.:e  >  of 
variable.  Although  the  translation  does  not  inc  1  t 
representation  specifications  ot  ;iuti  ,  I*  ci  n  . '  t  OO.'IS  1  Tii  . ; 

placed  on  integer  variables  when  possible  .  I  t  t  :.e  b 
integer  was  unsigned,  tnen  the  range  is  spec i : led 
0 . .2**<integer-size>-1  .  If  tne  integer  w..s  si  u  ,  t:.e:.  t 
range  oi  cue  resulting  equivalent  Ada  variable 
_  (2--'*<integer-size>-l  )  .  .2*';-'<integer-siue>-l  .  iioweVer,  t.. 
translation  still  uses  simple  additions  to  construct  t 
node  . 

J73  character  items  are  translated  into  Ada  objects 
type  STRING,  where  the  string  would  be  indexed  in  the  ran. 
1  . Xcharac ter- s ize> .  With  this  convention,  a 

<character-literal>s  can  be  translated  into  Ada  strings. 
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in  summary ,  che  translation  process  involves  chan jin  , 
adding,  deleting,  or  rearranging  elements  of  the  parse  tree 
in  order  to  have  the  parse  tree  represent  an  equivalent  An  . 
source  program.  Most  of  the  translation  routines  simply 
required  the  application  of  one  or  more  of  the  support 
procedures.  It  should  also  be  noted  that  a  good  many  of  tn 
translation  routines  required  no  action  at  all  except  ini- 
indicating  that  the  node  had  been  translated. 

Since  the  scope  of  this  research  project  could  not 
encompass  the  entire  translation  process,  JAIS  currently 
translates  only  a  subset  of  the  J7  3  language.  However,  the 
design  of  the  project  included  the  complete  translate': 
process  and  additional  translation  processing  ea  i  be  adde  : 
to  the  existing  system  without  major  modi f ica t Lons .  In 
order  to  make  the  current  translator  as  useful  as  possible, 
the  subset  of  J73  tnat  has  been  translated  was  selected.  i  > 
cover  as  much  common  usage  of  the  language  as  possible. 
This  includes:  (1)  basic  program  structure,  (2)  data  item 
declarations  and  type  declarations,  (3)  procedure 
definitions,  and  (4)  most  basic  statements.  A  summary  of 
the  translated  productions  is  contained  in  Appendix  B. 

To  aid  the  user  in  identifying  any  sections  of  J7J  code 
that  may  not  have  been  completely  translated,  some  method  of 
marking  each  node  as  having  been  translated  or  not  must  he 
used.  The  technique  used  in  this  system  is  an  array  of 
boolean  variables  that  correspond  to  each  node  of  the  tree. 
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zed  with  the  value  FALSE  and 


The  eriLi.ee  array  is  iuxth*  e 
NODE(I)  is  translated  the  corresponding  value  :  r 
TKAN'FLAG(I)  is  set  TRUE.  This  will  then  be  used  during  t.n 
prettyprint  process  to  identify  the  sections  of  code  tn.m 
were  not  translated. 

Prettyprint  Modulo 

The  usefulness  of  an  automated  translator  system  wool  ! 
be  questionable  if  the  format  of  the  output  was  difficul'  :  ■ 
interpret.  In  order  to  get  the  most  out  of  tie  translation, 
the  resulting  program  should  display  the  structure  of  t  ;<■ 
language  as  much  as  possible.  The  Ada  reference  manual 
suggests  some  formatting  conventions  ti  displiy  the 
structure  of  the  language.  The  prettyprint  module  outpi:  > 
the  translated  program  using  these  formatting  convent  to  ;•  . 
The  lexical  elements  that  will  make  up  the  Ada  program  an 
the  leaves  of  the  translated  parse  tree  and  are  outp  :t  fr 
left  to  right.  Indentation  and  line  breaks  are  control! 
through  the  use  of  a  case  statement  locking  for  portico!;- 
reserved  words  and  symbols.  For  example,  witn  the  exception 
of  a  formal  parameter  list  in  a  procedure  definition,  the 
semicolon  is  a  statement  terminator  and  is  used  to  generin 
an  end-of-line  and  carriage-return.  Another  example  is  the 
reserved  word  ELSE,  which  must  be  output  two  spaces  to  the 
left  of  the  current  tab  marker  while  the  statements  between 
the  ELSE  and  END  IF  are  output  at  the  tab  marker. 
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Also  output  during  the  prettyptint  process  are  warning 
messages  that  identify  sections  of  code  that  have  not  bee 
translated  and  require  user  translation.  This  allows  the 
user  to  quickly  identify  those  sections  of  code  which  wi ' 
require  attention. 


Conclusion 

JATS  is  a  fairly  complex  language  processor  that 
consists  of  three  functional  modules.  The  parser  mod.:!'' 
which  was  developed  using  the  LLNb  software  pagka,  • 
constructs  a  parse  tree  of  the  J73  program.  Tne  translation 
module  modifies  the  parse  tree  to  represent  an  equivy i on : 
Ada  source  program.  Finally ,  the  prettypriut  nodule  builds 
a  formatted  text  file  to  allow  the  user  to  edit  the 
translated  source  code. 


However,  the  user  shojld  he  a ware 
limitations  of  JATS  and  some  of  the  problems 
syntax  translation.  These  will  be  discussed 
section.  Still,  JATS  should  prove  valuable  for 
Ada  to  current  J73  programmers. 


of  S e V e V  :  1 
O  f  .1  L  "  • 
in  the  ne  ' 


int rwduu  ' 


36 


V  Resales  and  Re common 


The  primary  result  of  this  research  project  is  a 
translation  system,  JATo,  which  provides  a  limits: 
capability  for  J7o  users  to  automatically  translate  J'j 
programs  into  equivalent  Ada  programs.  Any  user  mus  _  b<_ 
cautioned  on  several  points  before  using  JATS.  The  most 
obvious  caution  is  that  JATS,  as  it  is  current!. - 
implemented,  is  incomplete  and  places  several  res t r ic t ions 
upon  the  user.  These  include:  (l)  use  of  u.u>  single  quota 
in  J73  declared  <name>s  must  conform  to  the  use  of  tit 
underscore  in  Ada  and  the  use  of  the  dollar  si;n  is  nor 
allowed,  (2;  J73  <name>s  cannot  be  Ada  reserved  wo rd*  , 
(3)  <block-preso t>s  are  not  allowed  in  progr  >  >  to  be 
translated  ,  (-.!  size  specifiers  in  some  da  t  a  dec  iar  at  ions 
have  limited  definitions  as  shown  in  table  1,  and  <^j)  use  >f 
DEFINES  is  not  allow  since  the  mechanism  for  process  i  ig  Liu 
DEFINES  has  not  yet  been  incorporated  in  JATo.  A  summary  of 
the  translated  J7 3  language  productions  is  cont  lined  in 
Appendix  B. 

Another  point  that  all  users  of  JATS  should  he  aware  of 
is  that  JATS  translates  a  J73  algorithm  into  an  equivalent 
Ada  algorithm.  This  means  that,  while  tae  translated  code- 
will  be  correct,  the  translated  version  may  not  make  use  of 
the  features  of  Ada.  Such  an  example  is  the  use  of  declare! 
boolean  flags  to  carry  an  error  condition  through  the  code. 
During  the  translation  process,  the  code  will  be  transi  t'  <•  I 


correctly  but  Ada's  exception  handling  techniques  would, 
probably  be  more  appropriate.  This  defficiency  is  not 
unique  to  JATS  but  is  an  inherent  problem  in  automati  : 
translator  systems. 

With  these  limitations  in  mind,  JATS  was  tested  against 
small  example  J73  programs  that  primarily  consisted  of  t'.ic 
translatable  language  constructs.  In  all  tested  cases, 
translation  was  correct  where  possible  and  those  sections  of 
code  that  were  not  translated  were  properly  identified.  One 
exception  to  this  result  is  the  WHEN  OTHERS  case  alternative 
in  the  Ada  version  of  the  case  statement.  It  will  be  the 
first  alternative  in  the  translated  version  rather  than  the 
final  alternative  of  the  case  statement.  An  example  J  7  3 
program  and  its  translation  is  provided  in  Appendix  E. 

This  research  project  not  only  produced  a  valuable  tool 
to  aid  in  the  transition  to  Ada  as  the  DoD  standur  i 
programming  language  for  embedded  computer  systems  but  als> 
provided  the  author  with  an  invaluable  experience  in  the 
development  of  language  processing  software.  A  task  of  this 
magnitude  presented  a  real  challenge  for  the  author  in 
several  areas:  (1)  grammar  analysis,  (2)  parsing  techniques, 
and  (3)  translation  techniques. 

The  LK  automatic  parser  generator  package  from  LLNL  has 
been  used  at  AFIT  in  other  language  processors,  mainly 
compilers  and  interpreters.  This  project  added  a  translator 
to  the  list  of  projects  developed  using  LR.  It  also 
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required  modification  of  LRS  to  accept  <*  or  a  :  * 

grammar,  which  will  allow  future  users  to  process  la!\_e 
grammars  with  LRS.  However,  it  should  be  noted  that  Lk.-  :  . 
a  very  large  program  with  a  very  large  memory  and  process.-, 
time  requirement. 

One  other  area  that  required  considerable  effort  w.-. 
designing  an  LR(1)  grammar  for  J  7  3  .  Initially,  the  d"j 
grammar  was  obtained  from  Ml  L-STD- 1  539A  and  required: 
extensive  modification  to  produce  a  grammar  that,  was  LR(1). 
After  considerable  effort  to  produce  a  fully  Lk(1)  gram.. tar , 
an  LR(1)  grammar  for  the  executable  statements  of  J7y  v.«-; 
obtained  from  -So f tech  Inc.;  however,  several  problems  still 
existed  in  the  grammar  for  the  declarative  parts  o:  J7  j  an. :, 
as  a  result,  several  limitations  have  necessarily  De-eu 
placed  on  the  user. 

The  other  major  areas  of  effort  were  the  parsing  aid 
translation  processes  and  the  use  of  the  appropriate  da'.  t 
structures  for  efficient  utilization  of  resources  and  ease 
of  translation.  Although  the  data  structures  the.nso!  v  .•  > 
were  not  new,  the  implementation  of  some  these  structures 
was  a  new  experience  for  the  author.  An  example  of  this  is 
the  dynamic  allocation  algorithms  and  the  use  of  the  OVERLAY 
declaration  to  allocate  the  same  memory  to  two  different 
data  structures,  the  tree  nodes  and  a  linked  list  of 
available  nodes. 

The  process  of  translation  als  j  identified  sever  k. 
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areas  that  present  some  difficulties.  Tne  trrinsl.it  ion  ,> : 
bit  variables  will  require  real  work.  If  the  bit  variable 
has  a  size  of  one  bit,  then  it  can  be  translated  into  i 
boolean  variable,  and  the  bit  literals  of  ‘1’  and  'O’  can  b, 
translated  into  the  boolean  literals  TRUtt  and  FALRi'. ,  • 
respectively.  However,  if  the  bit  variable  is  larger  than 
one  bit,  then  the  translation  must  create  an  abstract  Jit, 
type  that  will  allow  the  bit  literals  to  be  translated 
easily.  Also  required  during  translation  of  bit  literals  i- 


consideration  of  the 

bead 

size.  Tne 

bead  size  of 

• 

literal 
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the 

weight  of 

each  character 
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literal 

string  such 

that 

a  bead  size 

o  i  1  6  i  n  d  i  c  ites 

t. 

the  string  represents  a  hexadecimal  value.  The  valid  be  »  : 
sizes  range  from  one  to  sixteen.  In  other  words,  the  oetk 
bit  literal  3B'24'  is  equivalent  to  the  binary  bit  liter  k. 
1 B'010100*  and  some  convention  of  translating  the  hi’ 
literals  must  be  established  depending  upon  the  specific 
data  structure  used  to  implement  the  bit  variables. 

The  translation  of  parameter  lists  for  subroutines  will 
also  be  a  serious  problem.  In  J73,  the  typing  of  the 
parameters  occurs  during  the  processing  of  the  declarations 
in  the  <subroutine-body> .  However,  Ada  requires  that  the 
type  of  the  parameters  be  included  in  the  parameter  list. 
Therefore,  translation  of  parameter  lists  will  require  the 
generation  of  new  type  declarations  from  the  declarations 
that  are  "hidden"  further  down  the  parse  tree,  so  that  t'.< 
type  names  can  be  used  in  the  parameter  lists.  Declare;  -  . 
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of  some  of  the  data  items  will  also  require  generation  o: 
new  type  declarations,  for  example  floating  and  fixed  dut  , 
items . 


Other  items  that  are  not  directly  translatable  are  the 
directives.  Some  of  them  will  translate  to  equivalent  Ada 
pragmas  but  others  have  no  counterpart  in  Ada.  For  example, 
the  COPY  directive  corresponds  to  the  INCLUDE  pragma  but  the 
register  directives  have  no  equivalent  pragmas  in  Ad,!. 

One  additional  experience  gained  by  the  author  was  i  i 
the  use  of  J73.  Although  experienced  with  several  other 
block  structured  languages,  J7J  still  presented  some  ru-v 
experiences,  especially  since  the  language  and  compiler  are 
still  evolving.  However,  J7J  was  an  enjoyable  language  to 
work  with;  the  only  real  problem  encountered  was  the  lack  of 
execution  time  error  diagnostics,  which  sometimes  made  in.- 
debugging  process  difficult. 

A  project  of  this  magnitude  very  often  leaves  room  lot- 
future  work,  and  several  areas  have  been  identified  as 
candidates  for  continued  development  efforts.  These 
recommendations  are  listed  below. 

1.  Modify  JATS  to  translate  J  7  3  as  defined  in 
MI L-STD- 1  589 B  .  The  current  version  translates  M1L-STD- 1 5S9A 
and  the  B  version  was  released  too  late  to  be  included  in 
this  research  project.  However,  JATS  was  designed  to  all).-.- 
a  redefinition  of  the  input  grammar  without  major 
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modifications  to  JATS.  It  snould  be  noted  that  the  sour: 


code  for  JATS  itself  currently  conforms  to  MIL- STD- 1 589 b . 

2.  Complete  the  translation  module.  As  currently 
implemented,  JATS  is  incomplete  and  cannot  translate  all  of 
J73.  The  addition  of  the  remaining  translation  routines 
will  allow  JATS  to  automatically  translate  more  of  the  J?J 
syntax.  JATS  was  designed  to  allow  the  addition  of  the 
missing  translation  routines. 

3.  Add  the  capability  to  process  external  flies  s  ' 
that  COMPOOL  and  COPY  directives  can  be  used  in  the  .17  j 
program.  This  will  require  the  construction  of  the  s'.’mb.il 
table  for  the  declarations  that  are  contained  in  the  compool 
module,  and  scanning  of  the  external  file  for  tne  COPf 
directive  . 

4.  Improve  the  translation  process  by  making  i: 
interactive  and  allow  the  user  to  identify  sections  of  cod. 
that  require  manual  translation.  This  would  be  possible 
using  the  currently  available  SKIP,  BEGIN’,  and.  K'L; 
directives.  Then  JATS  could  allow  the  user  to  specify  tin 
translated  code  interactively  for  the  identified  code  an  i 
for  any  difficulties  that  the  translator  may  encounter. 

This  research  project  incorporated  the  use  of  various 
techniaues  in  several  topic  areas  and  resulted  in  a 
challenging  and  rewarding  experience  for  the  author.  The 
author  hopes  that  this  project  will  generate  continue  ! 
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interest  in  the  subject  areas  ot  Ada  and  auto 

translator  systems. 
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LR ,  Automa tic  Parser  Generator  and  L R ( 1 )  Parser 

"LR  is  a  pair  of  programs--an  automatic  parser 
generator  and  an  LR(1)  parser.  The  parser  generator 
reads  a  context-free  grammar  in  a  modified  BNF 
format  and  produces  tables  which  describe  an  LR(1) 
parsing  automaton.  The  parser  is  a  suite  of 

subroutines  which  interprete  the  tables  to  construct 
a  parse  of  an  input  stream  supplied  by  a  (locally 
written)  lexical  analyzer.  The  entire  system  may  be 
used  to  generate  parsers  for  compilers,  utility 
routines,  command  interpreters,  and  the  like.  bn 
and  its  predecessors  have  been  in  use  at  Lawrence 
Livermore  [National]  Laboratory  (LL[N]L)  for  ten 
years.  LR's  outstanding  characteristic  is  the  can.1 
with  which  new  tables  can  be  generated  to  reflect  ■ 
change  in  the  language  to  be  parsed.  inis 

flexibility  is  prized  by  programmers  writ  L 

utilities  and  command  interpreters  whose  input 
languages  typically  grow  and  change  during  progr.r 
development.  LK  is  written  entirely  in  AN.V. 


s  tandard 

FORTRAN  66  and 

requires 

onl  ■'  minor  chan  •  t-  ■ 

when  moved 

to  a  new  conpu 

ter”  (Ref 

1  O':  1  )  . 

LR  was 

an  important 

part  of 

the  J AT n  soft* 

development . 

Major  Michael 

Wirth  ha 

s  been  instru non:  -i'. 

promoting  the 

use  of  LR  in  the  develop 

men:  of  compilers 

interpreters 

at  AF1T.  A 

complete 

unders Landing  of 

requires  knowl 

edge  of  formal 

lan  ;ua  ,e 

theory  but  is 

required  to 

use  the  package.  Howev 

er,  for  the  in  teres 

reader,  an  understanding  of  the  data  structures  used  in 
parser  tables  is  helpful  in  understanding  the  pars 
process  . 


The  parsing  tables  produced  by  LRS  consist  of 
collection  of  arrays,  FORTRAN  dimensioned  variables,  t 
contain  the  control  information  for  the  finite  st 


automaton  which  performs  Che  parsing. 

The  vocabulary  of  the  language  is  described  using  two 
arrays,  V  and  VOC.  V  contains  a  contiguous  stream  of 
character  strings  which  are  the  vocabulary  elements.  VOC 
contains  pointers  into  V  to  identify  the  start  of  tic 
vocabulary  string  that  has  the  token  number  which  is  fit- 
index  into  VOC.  Figure  9  illustrates  this  relationship  and 
shows  that  the  token  number  for  the  reserved  word  P KOOK AM  is 
133. 


Fig  9.  Vocabulary  Data  Structure 


The  transition  data  is  contained  in  three  arrays:  FTKN, 
TRAN,  and  ENT.  FTKN  contains  pointers  into  TRAN  which 
contains  a  set  of  state  numbers  for  possible  transitions. 
ENT  contains  the  token  number  of  the  required  lookahead 
symbol  for  a  transition  to  that  state.  Figure  10 
illustrates  this  structure.  Thus,  for  a  given  state,  S,  a 


47 


Fig  10.  Transition  Data  Structure 


search  of  the  possible  states  in  Tk-\h  for  an  all  owab l 
transition  based  upon  the  current  lookahead  symbol  and,  t'u 
entrance  symbol  will  identify  the  next  state  of  t’u 
automaton.  Thus  as  shown  in  figure  10,  from,  state  S  .1 
transition  to  one  of  five  states,  SI,...,  Si,  is  possible 
based  upon  the  lookahead  tokens  T1,...,T5,  respee t i ve ly  . 


The  reduction  data  is  contained  in  seven  arrays:  FELL), 
NSET,  LSET,  LS ,  PROD,  LHS ,  and  LEN.  LS  and  LSET  define  t'u 
lookahead  sets  where  LS  contains  the  lookahead  sets  as  a 
contiguous  array  of  integers,  representing  the  token 
numbers,  and  LSET  identifies  the  beginning  of  each  lookahead 
set.  Therefore,  each  lookahead  set  can  be  identified  by  its 
index  into  LSET.  NSET  contains  collections  of  lookahead  set 
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numbers  and  FRED  contains  pointers  int.  eSEi  wnicn  idem 
the  collection  of  lookahead  sets  which  apply  for  the  g 
reduction.  If  one  of  the  lookahead  sets  of  the  given  st 
S,  contains  the  current  token,  PROD(S)  contains  the  lang 
production  number  that  will  be  used  to  perform 
reduction.  Figure  11  illustrates  this  relationship . 


K  K+i 


Fig  11.  Reduction  Data  Structure 

Thus,  for  a  given  state  S,  FRED  identifies,  through  NSST 
LSET,  which  lookahead  sets  must  be  checked  to  allow 


i  v  e  ■ ) 
* o , 
Li  4  i.* 

the 


and 

the 
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reduction  in  PROD  to  be  useu  bases  on  t.i<_-  curt..-  u  siv.c  : 
current  lookahead  symbol.  The  remaining  two  arrays  c  >n:  »:  - 
the  reduction  information.  LEN  contains  the  length  of  •.  u 
righthand  side  of  the  production  and  LHE  contains  the-  turn  , 
number  of  the  symbol  on  tne  lefthand  side  of  the  production,  * 
When  the  reduction  is  performed,  LEN'  will  indicate  th. 
number  of  elements  that  will  be  popped  off  of  the  stacks  a  . 
LHS  contains  the  token  number  that  will  be  pushed  on:  >  t'i. 
token  stack. 


Note,  these  data  structures  are  produced.  wi:  .  t  .< 
FORTRAN  66  option  for  table  structure  and  were  retained  .  : 
JATS  in  order  to  use  the  same  parsing  algor i turns  tuiv  *v -e 
supplied  in  PKo. 


However,  before  a  co  nplete  set  of  parser  tables 
generated  several  changes  were  required  to  all  rw  L.-. 
accept  the  large  J73  grammar.  These  changes  invoice 
increasing  the  sizes  of  some  of  the  dimensioned  vuriu 
and  other  related  variables.  The  string  storage  for  ih< 
input  grammar  was  limited  by  the  dimension  of  SSTORE  and  th. 


value  of  MAXSST. 


To  allow  for  the  large  mn'u 


productions,  the  value  of  MXPROD  and  the  dimens  inn  of  PkUIN..' 
had  to  be  increased.  Also  dependent  upon  the  number  of 
productions  was  the  dimensioned  variable  ‘1ARK  within 
subroutine  COMPLT.  The  storage  of  reduction  and  transition 
data  was  limited  by  the  dimensions  of  RED  and  TRAN, 
respectively,  and  the  values  of  MARKED  and  MAXT*\N, 
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1 


respectively.  Other  dimensioned  variables  use.:  :  ,  fa 
grammar  analysis  that  had  to  be  increased  in  sice  we  :  . 
BASIS,  NEXT,  ITEM,  and  PRODCN.  Tnese  changes  are  summarised 
in  table  III  . 


TABLE  III. 


Changes  to 

Dimens ioned 

V  a  r  i  a  t>  l  e 

s  o  i  L  r. 

Dimensioned 

Dimens 

ions 

Relate 

Variable 

Old 

New 

^  d  r  l  'M 1  > 

SSTOKE 

3000 

lOOOu 

PRDIND 

500 

1  0  JO 

P  i\  j.. 

TRAN 

4000 

26000 

M  AX i  -M 

KLJ 

4000 

3000 

'  k.'  V» ,~\  *  .  .  , 

NEXT 

5000 

8000 

4..  ^  W 

ITEM 

5000 

8  Ju  3 

.  4.  ^  . 

BASIS 

800  0 

J  *4  J  0  0 

.  4.  V/  .  .0  ,  .  1 

PRODCN 

4000 

o.iOO 

X"  1 

.  ;  \  <»v. 

MARK 

500 

1  j 

*  ‘ .. 

Tiie  other  change  that  wa s  :»•  •.  >  LHS  w,n  !  >r 

convenience.  Another  subroutine,  called  O'.'l'l'Ab,  was  ad  !•■  1 
which  created  separate  output  tiles  for  toe  parser  tables 
and  grammar  analysis.  Tnis  change  required  ti;-* '  ill  calls 
to  OUTPUT  within  subroutines  TABLES  ana  HLDDMP  be  changed,  to 
OUTTAB . 
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J7 3  Language  Produc  t  ions 

The  following  list  is  the  language  productions 
output  from  the  grammar  analysis  of  LRS  .  Those  product i>> 
that  have  been  translated  are  preceeded  by  an  aster  is,-. . 


1  <SYSTEM  GOaL  SYMBOL>  =  END  <  COM?  L  ET  K - P  ROG RAM >  END 
*2  <COMPLETE-PROGRAM>  : :=  <MODULE> 

*3  /  <COMPLETE-PR0GKAM>  <MODULEP 

*4  <MODULE>  ::=  <COMPOOL-MODULO 
*5  /  <P  ROC-MODULO 

*6  /  <MAIN- PROGRAM- MOi)UEE> 

7  <COMPOOL-MODULE>  ::=  START  <  COMPOUND- COMPOOO  <N  'CM.  > 

<COMPOOL-DEC-LIST>  <COMPOL’N.  -Tr-R 

8  /  START  < COM P  0  U  N  D- COM  P  JO  L  >  <NA.L.  > 

<COMPOUND-TEKM> 

*9  < COMPOUND- COM POO L>  : :=  COMPOOL 
*10  /  <DIR£CTLVt>  < C 0 M ? J U N D - C ■  i M i ’ ■  j • 

11  <P ROC- MODULO  :  :=  START  <DEC-LIST> 

<NON- NESTE D-SU B-  LI  S  O  < C O M P 0 U N D -  T ;-.R 

12  /  START  <NON-NESTED-SUB-L!  SO 

<COMPOUND-TEKM.> 

*13  <NON- NESTED- SUB-L I ST>  :  :=  <NON-NESTEU-SU:i  > 

*14  /  <NON-NESTED-SUB-LI S O 

<NON-NESTED- ST  H> 

13  <NON- NEST  ED- S’JB>  =  DEF  <SUB-DEF> 

*16  /  <SUB-DEF> 


*17  <MAI N- PROGR.AM-MODULO 

::=  START  < COMPOUND- PROGRAM>  <NAME>  ;  <COMPOUND- BOD 
<NON-NESTED-S'JB-  LIST>  < COM P 0 U N D - Th K M > 


*18 


START  <COMPOUND-PROGRAM>  <NAMO 
<COMPOUND-TERM> 


<COMPOUND- 30 D 


*19  /  START  <COMPOUND-PROGRAM>  <NAME>  ;  <STMT> 

<NON-NESTED-SUB-LIST>  <C0MP0UND-TERM> 

*20  /  START  < COMPOUND- PROGRAM>  <NAME>  ,  <STMT> 

<COMPOUND-TEKM> 


r 


*21  <COMPOUND-PROGRAM>  ::=  PROGRAM 

*22  /  <DI RECTI VE>  <COMPOUNl)-PRJGR\ 


*23  <COMPOUND-BODY>  ::=  <PROGRAM-BODY> 

*24  /  <DIRECT1VE>  <COMPOUND- BODY > 


*25  <COMPOUND-TERM>  : :=  TERM 

*26  /  <DIRECTIVE>  <COMPJEGD-TEKM> 


*27  <PROCRAM-BODY> 

::=  BEGIN  <DEC-LIST>  <STMT-LIST>  <SUB-DEF-LI  S 1  ' 
<DI  RECl’-COMPOUND-END> 

*28  /  BEGIN  <DEC-LIST>  <3  TMT-L I  ST>OI  REG I- COM? JUND- 

*29  /  BEGIN  <ST:TI-LIST>  <SUB-DEF- LISTS 

<DIRECT- COMPOUND- ENDS 


*30  <DI RECT-COMPOUND-END>  ::=  <COMPOUND- END > 


*31 

/  <DIRECfLVE> 

<DI RECT-COMP JCMD- CN’4 

32 

<1  NT  EG  L  R- MACH 1 N E- PARAMET Ek> 

.  •  = 

BITS  IN  BY!-. 

33 

/ 

B1 rblNNOKD 

34 

/ 

LOGS  L  N  .,’0.0 

35 

/ 

BYT  ESI  NNO.O 

36 

/ 

BITS  L NPOIN TER 

37 

/ 

FLOArPKEGISMN 

38 

/ 

FIXEDPKEGL S ION 

39 

/ 

FLOATRAD I X 

40 

/ 

1MPLFLOATPKLGLSL  ON’ 

(  < FORMULAS  ) 

41 

/ 

IMPLF1XEDPREGL  .6  i  ON 

<  FO  RMU  LA  >  ,  X  FO  M  1JL 

42 

/ 

IMP LI  NTS  LEE 

(  < FORMULAS  ) 

43 

/ 

maxfloatpklglsion 

44 

/ 

MAXFIXEUPREGISION 

45 

f 

••lAXINTSiEE 

46 

/ 

MALI  BY  I  S 

47 

/ 

MAX B I  l  " 

48 

/ 

MAXI NI‘  (  < FORMULA-’ 

49 

/ 

l 

MINI  NT  (  < FORMULA^ 

50 

! 

MAX  STOP 

51 

i 

MiNsroP 

52 

/ 

MAXSIGDIGI  IS 

53 

/ 

MI  NS  1 Z  E  (  < FORM'S  LAP 

54 

/ 

MIN FRAG ri JN 

(  < FORMULAS  ) 

55 

/ 

mi  ns gale  (  < formula 

56 

/ 

Ml NRELPRECI SION 

(  <FORMULA>  ) 


57  < FLOAT ING-MACrtINE-P AR AMET X K > 

MAX  FLOAT  (  <FORMULA>  ) 

58  /  MINFLOAT  (  < FORMULA;  ) 
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by 

60 


/  FLOAT RELPRECI SION  (  <FOK:iL'LA>  ) 
/  FLOATUNDERFLOW  (  <FORMULA>  ) 


61 

<FIXED-MACHINE-PARAMETEK> 

:  :=  MAX  FI  X  E  D  (  <FORMULA>  , 

<F0RMULA>  ) 

62 

/  MI N FIXED  (  <FO RMULA>  , 

<F0RMULA>  ) 

*63 

<DEC-LIST> 

:  :=  <DEC-LIST>  <DEO 

*64 

/  <DEC-LIST>  <N 

DLL- STMT  >  <DEC> 

*65 

/  <NULL-STMT>  <DEO 

*66 

/  <DEC> 

*67 

<DEC>  : := 

<DATA-  DEO 

*6  3 

/ 

<TYPE-  DEO 

*69 

/ 

<SU  B-  DEO 

*70 

/ 

<STMT- NAME- DEO 

71 

/ 

<  D  E  F 1  N  E  -  D  E  O 

72 

/ 

<EXTEKNAL-  DEO 

73 

/ 

<  0  V  E  R  L  A  Y  -  D  E  O 

*74 

/ 

<1 NL1 NE- DEC  > 

*7  b 

/ 

BEGIN  <DEG- LI ST>  E 

*  7  o 

/ 

/ 

<D1 RECTI VE>  <DEO 

77 

CCOMPOOL-D 

EC- LI  SO  ::=  <CDMP 

)0l-dec-l:  s :  >  \C 

78 

/  \C  JM:’ 

JOi.-DE.  > 

79 

<COMPOOL-D 

EO  :  :  =  <EXn.-NN.C-- 

DE  > 

60 

/  <Ci)NS T.iN  1  - 

J  "> 

81 

/  <TYPE-DEO 

82 

/  <DEFINc.-DL 

C> 

83 

/  <0V EK LAY -D 

{ v !  > 

84 

/  <NL'LL-STMi 

> 

6  3 

/  BEGIN  <CO.M 

POOL- DEC- LI F 7  "  EN 

86 

/  <DI  RECTI  AO  <C  )■)..-  DP  ' ' 

*57 

CDATA-  0 l v- ^ 

:  :=  <1  Ir.M-DEO 

*88 

/  <TABLE-DE  :> 

*39 

/  <C0NSTAN  i'-  DEC 

*90 

/  <  BLOCK- DEO 

*91 

<  ITEM- DEO 

: :=  ITEM  <NaME>  < 

OLflCATlON-SPECI  F 

<1 TEM-TYPE- DEsCkI P  Ti  JN  ■ 
<  I T  E  M  -  P  R  E  S  E  T  -  0  P  T 1 0  O  , 


*92  <ITEM-TYPE-DESCRI PTIONb 

:  :  = 

<1N  I' EG EK  -  IT DESCkI  PI'I 

*93 

/ 

<FL  BATING- ITEM- DESCkI  P r 

*94 

/ 

< FIXED- I r EM- DESCkI P I ION 

*95 

/ 

<BI  r-I  rEM-DESCRI  prioo 

*96 

/ 

/ 

<CHARACTEk-I TEM- 

DESCKI PrioN > 

*97 

/ 

<STATCS- ITEM- DESCKI  PIT') 

*93 

/ 

<pointek-i tem-descki  pi: 

*99 

/ 

<1  fEM-TYPE-NAMO 

bn 


*100  <INTEGER- I TEM- DESCRIPT IONS 


=  <S-0R-U> 

<R0l'ND-  OR-  TRUNCA  I  r> 
<  FORME' LA  > 

*101  /  <S-OR-l’>  < FORMS’ LA> 

*102  /  <  S  -  0  R  -  U  > 

*103  /  <  S  -  0  R  -  U  5 

<  ROU  N  D-  OR-  TKU  M  C  AT  E  > 

*104  <S-OR- US  S 
*105  /  U 


1  06  < FLOATING- 1 TE'-l-DESCRI  PTIONS 

107 
*108 
*1  09 


::=  F  <ROl’ND-OK-TRUNC  \ 
MFURMULA' 

/  F  < FORMS LA' 

/  F 

/  f  <ruund-o.-%-tkunca 


*110  <  ROUND- OR- T  RUN  CATO  ::=  ,  k 
*111  /  ,  T 


1  1 2  < FIX ED- 1 TEM- DSSCKI PTI UNS 

1  1  3 
1  14 
1  1  3 


:  =  A  < ROU N D-OR-I  r\U.L.A  1 
<FOrMULA>  ,  <Fo:\U.  '■ 

/  A  < FORMULAS  ,  <For.MU.. 
!  a  < Formula. > 

A  <RO'JND-OR- 1  RUN > 
<  FORMS'  LA  > 


116  <BIT- ITEM- DESCKI PTI ONS  ::=  B  < FORMULAS 
*117  /  B 


*118  <  CHARACTER- 1 TE  -1-  DESCKI  PTi ON'  ::=  C  <  FORMULAS 
*119  .  C 


120  < STATUS- 1 TEM- DESCKI PTL ON>  ::=  STATUS  <1 NTENEk- L! TE 


(  <s t.a r  ss  - Li  s  ;  >  ) 

121  /  STAT'S  (  <STA!"'S-Li  S 

122  <  STATUS  -  LI  STS  ::=  <  S  T  A  T  i '  S  -  C  0  N  S  T  A  N I  > 

123  /  < FORMULAS  XSlAIOS-CONblA.w  ; 

124  /  <STAIUS- LI ST>  ,  <STAIUS-CONb FAN  I 

125  /  (STATUS- LI STS  ,  < FORMULAS 

< S T  ATM S - CONS  TAN  T > 


126  <STATUS- CONSTANTS  ::=  V  (  (STATUsS  ) 

127  <STATUSS  :;=  < NAMES 

128  /  <L r R> 

129  /  < RESERVED- CORDS 

130  <POINTER-I rEM-DESCKIPTIONS  : :=  P  <TY PE- NAMES 

131  /  P 

132  <TAbLE-DEC>  :  :=  TABLE  < NAMES  (ALLOCATI ON- SPECI  FI  o- 

< DIMEN'S  ION-  LI  STS  (TABLE- DESCkI  P  l  ) 
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133 

CTABLE-DESCRLPTiCR.-  ::=  CSTRUCTUKE-SPECL  FL  Hr;.' 

CENTRY-SPECI FI EK> 

134 

/  CENTRY-SPECI FL  EK> 

135 

/  CTABLE-TYPE-NAMES  , 

13b 

/  CTABLE-TYPE-NAMES 

< TABLE- P RES ET>  ; 

137 

<ENTRY-SPECI  FI  EK>  ::=  <ORDI  NARY- ENTRY  -  SPE  Cl  FL  EK'* 

138 

/  CSPECL  FI  ED- ENTRY- SPEC! FL  EK  ■ 

» 

139 

<DIMENSLON-LIST>  : := 

143 

/  CDLMENSLON-LI ST-HEAM  •  ) 

141 

<DI MEN'S! ON-LI ST- HEAD >  :  :=  (  CDLMENSLONS 

142 

/  < DI MENS 1 ON - L I  ST- HE \  • 

<dimenslo:;> 

: 

143 

<DLMENS10N>  :  :  =  < LOWER- BOUNDS  CFOKMCEV' 

1  44 

/  < FORMULAS 

145 

/  '' 

146 

< LOWER- BOUNDS  ::=  < FORMULAS  : 

147 

<S  TKUCTURE-SPECI  FL  EK>  ::=  PAR  A  LI,  EL 

14S 

/  T  ClNTHNEr.-L:  LEkAE  ' 

1  49 

/  t  <fllncl'l  in -'.alls 

1  50 

'  t  cname  > 

151 

/  i 

1  52 

<ORDL NARY- ENTRY- SPECI  FL  Er > 

:  :=  <PACKLNG-SPECLFLER>  Cl  TEM-TY'P  E  -  DHS-  -A  i  1  o:."* 

<TABLE- PRESETS  , 

1  53 

/  CPACKI NG-SPECL  FL  EX>  CITEM-TYPE-DE.'O  l PL 1  >N  •  , 

1  54 

/  <L  TEM-TYPE-DESCKI  PT i JNS  <1 ABE-- PR  IS  L  •  , 

1  55 

/  <i  te.-i-type-descri  plio:;  >  ; 

1  5b 

/  CTA3LE- PRESETS  ;  <ORDI  NARY -TAr>EH-  •> 

I 

157 

/  ;  CORDL NARY-TABLE- BODY > 

1 

1  58 

/  CPACKI NG-SPECl  FL  HKS  <TA»LE-PREsE L >  ; 

1 

<ORD  L  NARY - TABL  E- BO  DY  > 

1 

1  59 

/  <PACKL  NG-SPECL  FLEkS  ;  <0RD1  NARY -TABLE- -vK'Y  • 

1 

ICO 

<P AC KL NG-SPECL FLERS  ::  =  N 

] 

161 

/  M 

1 

1  62 

/  D 

I 

163 

<ORDI  NARY-TABLE- BODY  >  ::=  <ORD  I N  A  nY  -  TA  rsEH-IT  E  M-BB 

1 

164 

/  BEGIN  <ORDLNARY-TABLE- 

I 

0PT10NS-LIST >  HN. 

1 

165 

CORDL NARY -TABLE- ITEM- DECS 

1 

:  :  =  ITEM  < NAMES  <1 TEM-TY PE- DESCR T P T I ONS 

1 

CPACKI NG-SPECL FLEKS  CTABLE-PRESE r>  , 

j 

1  6b 

/  ITEM  < NAMES  CITEM-TYPE-DESCKl  P T 1  0N,> 

1 

CPACKI NG-SPECL FLEKS  ; 

] 
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J 

i  67  /  ITEM  <NAME>  <1  r EM- TYPE- DESCKL  ?T10::  « 

<TABLE-PRESET>  ; 

168  /  ITEM  <NAME>  <1 f EM-TYPE-DESCRI P r LON> 

1 69  <ORDI NARY- TABLE- OPTIONS -LIST) 

:  : =  <ORDI NARY-TABLE- OPT LONS -LI  ST  s 
<ORDI NARY -TABLE -OPT IONS > 

170  /  <ORDI NARY -TABLE- OPT1 ON S> 


171  <ORDINARY-TABLE-OPTIONS> 

172 

173 


:  :=  <ORDI NARY- 


TABLE-  I  TEM  - 


/  <DI RECTI VE> 
/  <NL’LL-ST'-li  ' 


1 74  <SPECIFLED- ENTRY -SPECIFLER) 

:  :=  <WORDS-PER-ENTRY>  <SPECI FL  ED- 1 1 EM- DESCRIPII 
<TABLE-PRESET>  ; 

175  /  <WORDS- PER- ENTRY >  <5PECI FLED- I TEM-DESCrI FT  I 

176  /  <WORDS- PER- ENTRY >  <TABLE- PRESS  D  ; 

<SPEC1 FL ED-TABLE- BODY) 

177  /  <WORDS- PER- ENTRY >  ;  CSPECL  FI  ED-TABLE-  S  - 


178  <WORDS- PER- ENTRY >  ::=  W  <INI’ENr>.-LITEr,nL'> 

179  /  W  < FC NOTION- CAL 

180  /  w  <na::e> 

181  /  N 

18  2  /  V 


183  <SPECl FL  ED-ITEM-DESOk: P  f  1  oO 

::=  <1  TEN-  TYPE-DESOKl  PII  ON)  P-JS 
(  <LOCATION-SPECI  FL  Er.  >  ) 

184  <LOCATI  ON-SPEOI  FL  EK>  ::=  <STAKTL NO- B1  1  >  ,  CFOrNl 

185  <STARTI NO- BIT)  ::=  <FOKMOLA> 


187  <SPECI FI  ED-TABLE- BODY)  ::=  <SPEOi  FL  ED-TABL:  -  1  I 
183  /  BENIN  <S  P  EC  i  F  L  ED-  I A  BEE 

OPTIONS- LIS :  > 


1  89  <SPECL  FI  ED-TABLE-ITEM-  DEO 

:  :=  ITEM  <NAME>  <SPECI  FL  EL)- 1 IEM- DESCKI  P 1 1  ON'' 
<TABLE- PRESET)  ; 

190  /  ITEM  <NAME>  <SPECI FI  ED- ITEM- DESCkI P IL  )N  <  , 

191  <SPECI FI ED-TABLE-OP TIONS- LI ST) 

: :=  <SPECI FI ED-TABLE-OPTIONS-LI ST > 

<SPECL  FL  ED- TABLE-OPTIONS > 

192  /  <SPECI FLED- TABLE- OPTIONS) 

193  <SPECI FI ED-TABLE-OPTLONS>  ::=  <SPECL  FL  ED-TABLE-IT 

DEO 

194  /  <DI KELT L YE> 

195  /  <.\YLL-STMi  > 
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*196  <CONSTANT-DEC> 

::=  CONSTANT  ITEM  <NAME>  <ITEM-TYPE-DESCKI P 
<FORMULA>  ; 

197  /  CONSTANT  TABLE  <NAME>  <D1MENSI0N-LI ST> 

<TABLE- DESCRI PTION> 


198  <BLO('.K-DEC> 

::=  BLOCK  <NAME>  <ALLOCATION- SPECI FI EK>  ; 
<BLOCK- BODY-PART> 

199  /  BLOCK  <NAME>  <ALLOCATION-SPECi El EK> 

<BLOCK-TYPE-NAME>  <BLOCK-PR£SET>  ; 

200  < BLOCK- BODY - PART>  : : =  <NULL-STM1'> 

20 1  /  <DAT  A-DEO 

202  1  BEGIN  <BLOCK-  BODY-OP  TI  .) 

END 


203  <BLOCK- 30DY-0PTI ONS- 

204 


st>  : :=  <block-booy-op: 

<BLOCK-BODY-OPr 
!  <BLOCK- BODY-OP  T 


205  <BLOCK- BODY -OPTION’S  '  ::=  <DArA-DEC> 

200  /  <OVERLAY-DE; 

207  /  <DL  KEd'L  v’E  > 

208  /  <NYLL-ST-;r> 


*209 

CAL LOCATION 

-SPECI FI 

EK>  :  :  ■= 

210 

t 

ST.-C 

*21  1 

<rr  em 

-  PRES  E 

r-oprio;: 

;>  .  .  . 

2  1  2 

/  = 

<  FO  K 

213 

CTABL 

E-PRES 

,;r>  .  .= 

=  <TABL: 

■>PRE 

2  1  4 

/ 

=  <NYLL- 

-PRES 

215 

<NL’LL 

-PRESS 

;■  >  .  .  - 

216  <TABLE- PROSE  T- L I ST>  ::=  <DE FYYL ! - PR ESE 

217  /  KCOMPOYND- PRES 


S  7  .j ..  1 
-SYS.. 


218  <DE FAULT-  PRES E  I'-SUBLI  ST> 

::=  < FORME LA > 

219  /  <  R  E  P  E  AT  rl  D  -  P  R  E  S  E  T  -  V  A  L  Y  E  S  -  0  P  T 1 : 1 :  Y  ■ 

220  /  <DEFAULT- PRESET- SUBLIST- HEADY  <FOK/.YL-\  ‘ 

221  /  <DEFAULT- PRESET-SUBLI ST-HEAD >  <NY LL-PKE 

222  /  <  D  E  F  A  U  L  T  -  P  R  E  S  E  T  -  S  l!  B  L  L  S  T  -  H  E  A  D  > 

<  R  E  P  E  A  T  F.  D  -  P  R  E  S  E  T  -  V  A  L  0  E  S  -  0  P  T I  J I  Y 

223  <DEFAULT-PRESi;r-SUBLIST-HEAD> 

.;=  <PRESET-VALUES-0PT10N>  , 

224  /  <default-preset-sublist-hea:)> 

<PKESET-VALl’ES- OPTIONS  , 
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225  <COMPOUND-  PRES  £T- SUBL I  ST  > 

:  :=  <  COMPOUND- PRES ET- SUBL I S  F- HEAD >  <  FORMULA. 

226  /  <  C  0  M  P  0  U  N  D  -  P  R  E  S  E  T  -  S  U  B  L I S  I'  -  H  E  A  D  >  <NULL- PR; 

227  /  <COMPOUND-PRESET-SU BLI ST-HEAD> 

< REPEATED- PRESET- VALUES -OP  I ION> 

228  < COM POUND- PRESEr-SUBLIST-HLAD> 

: :=  <DEFAl’LT-  PRESET-Sl’BLI  ST- HEAD> 

<?reset-index-speclfi er> 

229  /  <PRESET-INDEX-SPECI FI ER> 

230  /  < COMPOUND  - PRES E  1'- SU BLI  ST-  HEAD "> 

<PRESE  r-VALUES-OPTI ON>  , 

231  /  <COMPOUND- PRESET- SUBLIST- HEAD  / 

<PRESET- INDEX- SPECI FI EE> 

232  <PkES£T- INDEX- SPECI FI EK>  <PRESE T-INDEX-SP: 

HEAD>  )  : 


233 

<  P  K  E  S  E 

ur- 

INDEX- SPEC 

L  FL  4 K- HE. 4 

D> 

:  :  = 

POS  ( 

< FORME 

LA  > 

234 

/ 

<PRESE 

T-INDE 

X  -  S  P  E  C I  F  L 

ER- H  LA 

235 

<pkese  r- 

\J  \  1  1  ’ 
v  r.iA 

ES-OP  : 

. ON  •  :  :  = 

23b 

v  t'JcV/.V 

237 

CaEPEA 
0  PEL; 

238 

<REPEA 

.IE 

D-Pk 

EsEl'-V 

aleeb-op: 

1 1 1 ;  i  > 

:  :  - 

<REPE I 

;  r l  on- 

LIST-HEAD 

>  <  F  0 

239 

/ 

<K 

EPE  I 

: riON- 

LIST-HEAD 

>  <NEL 

240 

i 

<  K 

EPE  I 

:  noN- 

LISI'-iOO 

s  K 

V  P  V  A 

:ed- pr 

ES  E  T-Y ALE 

r.S-OPI 

24 1 

<k EPEE 

i  C 

LON- 

LISI-H 

lad> 

:  ;  = 

<i 

-  >  *  Lo 

EK-LI  r 

EK/OL>  ( 

242 

/ 

EPE  I 

L TL ON- 

LI  ST- HEAD 

■  <  P  R  E 

243 

< BLOCK 

-p 

:\E.'  .I 

~  >  •  •  = 

244 

1 

=  < BLOCK 

_  \) w  .  •  ^  „• 

*245 

<TYPE- 

NA 

ME  > 

:  :=  <1 

TEM- TYPE- 

.VL  »UL  ? 

*246 

/  <T 

ABLE- TYPE 

-  4\a;  Vl  > 

*247 

/  <  B 

LOCK-TY  BE 

-NAME  > 

*248 

<TY  PE- 

DE 

C>  : 

:=  Of 

MI-TYPE-D 

A  A  > 

*249 

/  <TA 

BLF-TYPE- 

DEO 

*250 

/  <BL 

ik.K-TYPE- 

DEO 

*2  51  <1 TEM-TYPE-  DEO 


TYPE  CNAML'KI  TEM-TY'-'E-DESC. 


252  CTABLE-TYPE-DEO 


TYPE  CLIME  >  TABLE  <T  ABLE 
SPELL  FL  Er:  ■ 


3 


•J 


hi 

tv  v  I-:  - 


j 


253  <TABLE-TYPE-SPECI  FI  EK> 

::=  <DlMENi>ION-LIST>  <STKUC TORE- SPLCI  FL  Ek> 
<LIKC-OPTION>  <EN'TR\'-SPECI  Flc.K> 

254  /  <DIMENS10N-LIST>  <S  TRl’CTURE-SPECI  FI  Ek> 

<e:jtky-specifiek> 

255  /  <DIMENSI ON-LI ST>  <LI KE-OPT  1  DN>  <ENTRY-SPECI  FL 

256  /  <DIMENSION-LIST>  < E N I R  Y  -  S P 2 2 1 F L  2 K  > 

257  /  <DI  MEN'S  ION- LI  ST>  <  TABLE- TY  PE- NA!  IE  4  , 

258  <L1KE-0PTI0N>  ::=  LIKE  < TAbLE-TYPE-NAML  • 

259  < BLOCK- TYPE- DEO  ::  =  TYPE  <NAME >  BLOCK  '.K  LK-iLi- 

pak  r  > 

260  <  S  TM  r  -  NAME  -DEO  ::=  <STMT  -  NAME  -  D  E . :  -  H  • .  V.  :■  -  ; 

261  <  S  TMT  -  N  AME  -  D  E  C  -  H  E  AD  >  ::=  LA  ILL.  <NA. > 

262  /  <s Dir- name- dec-hod ••  , 


263  <DE FINE- DEO  :  :=  DEFINE  < NAMED  <DEr-PA:M  > 

264  <DEF-  PARTS  ::=  <  FORMAL-  DE  FI  Nc.-  PArw'E  IK  2  S  R-  L 

options  <oharamtek-s:v..  ;• 

26  5  <  FO K:  1AL -  DE  F I  N  E-  PA  FAME  1  R-  L I  S  i'  > 


260 

267 

263 


269 

270 
27  1 


273 

274 


!  <  FO KMAL -  D E  FI  N  E- PA RAM 7.  7  -  R-LI  S  7  -  :i 

<F0RMAL-DEF1NE-PAR AM E T E K -LIS  i'-Hu. A , > > 

: :=  (  <LTk> 

/  <FORMAL-DEFl  NE  -  PARAMETER- LI  S  I- HEAD  • 

<LI  S I-OPTIONS  :  :  = 

/  LISTEXP 
/  LI  STL  NY 
/  LIST  80  T  9 

< EXTERNAL- DEO  :  :=  <DEF-SPEO^ 

/  <REF-SPEO 


275  <D£F-SPEC>  : :=  <SIMPLE-DCF> 

2  76  /  <C0MP0uN’D- DE !•'> 

277  <SIMPLE-DEF>  : :=  DEF  <DEF-SPEC-CH01CE> 


278  <COMPOUND-DEF>  ::  =  DEF  BEGIN  <DEF-SPEC-CHOIO-LI  S  O  E 

279  <DEF- SPEC- CHOICE- LISTS  ::=  <DSF-SPEC-CHOICE-LIS  L’> 

<DE  F- SPEC- CHOI  CE> 

280  /  <DEF-SPEC-CHOICE> 

281  <DEF-SPEC-CHOICE>  :  :=  <NULL-STMI"> 

282  /  <DATA- DEC > 

283  /  <DEF- BLOCK- INSTANTIATION  “ 
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I 


284 

285 

286 

287 

288 

289 

290 

291 

292 

293 

294 

295 
29  o 

297 


298 

299 

300 

301 

302 

303 

304 

305 

306 

307 

*30S 

*309 

*310 
*31  1 

*312 

*313 

*314 

*315 

*316 


/  <STMI-NAME- DOC  > 

/  <DI RECTI VE>  <D£F-SPEC-CHUI CrS 

<DEF- BLOCK- INSTANTIATIONS  ::=  BLOCK  IN. ST ALOE  < NAMES  , 

<REF-SPECS  : :=  <SLMPLE-REF> 

/  < COM POUND- REFS 

<SIMPLE-REF>  :  :=  REF  <KEF-SPEC-CHOICes 

< COMPOUND- REFS  :  :=  REF  BEGIN  <RE F- SPEC- CHOI  CE-L L  S  E  >  EX! 

<REF- SPEC- CHOI C E-LI ST>  : :=  <REF-SPEC-CHOICE-LI ST> 

<REF- SPEC- CHOICES 
/  <REF-SPEC-CHOICE> 

<KEF- SPEC- CHOICES  ::=  <NULL- STMTS 

/  < DATA- DECS 
/  <SUB-DEC> 

/  <DI RECTLVES  <REF-SP EC-CHOl  .>.  > 

<  OVERLAY  -  DECS  ::=  OVERLAY  < A  BS  OLD  T  E-  AD  0  R  E  S  '  ' 

<OVEKLAY- EXPRESS  IONS  ; 

<ABS  OLL’TE- ADORES  S>  = 

/  P JS  (  < FORMULAS  )  : 

<OV  E rLAY- EX  PRESS  LONS 
;  ;=  (OVERLAY- S  i'K I  NGS 

/  <OV  E  RLAY  -EXPRESSIONS  :  <OVERLAY-STRI  NG  > 

(OVERLAY-STRINGS 

: :=  <OVE RLAY -ELEMENTS 

/  < 0 V  E  RLAY  -STRINGS  ,  <  0 V  E  KL  AY  -  E  L  F. M E  N  1  -> 

<OVE  RLAY - ELEMENTS  :  :=  <SPACEkS 

/  < NAME > 

/  (  (OVERLAY-EXPRESS  LON.*  ) 

<SPACEK>  : :  =  W  < FORMULAS 

<SU  B- DECS  ;:=  <PROC-DEC> 

/  (FUNCTION- DECS 

<SUB-DEF- LISTS  : :=  <SUB-DEF> 

/  (SUB-DEF-LIST3  <SCB-DEF> 

<SUB-DEF>  : :=  <PROC-DEFS 


/  < FUNCT L ON- D E  F> 

/  <DI RECTLVES  <SiJB-DEF3 


<PROC- DECS 

:  -.=  <P ROC- HEADINGS 

;  <DEC> 

<PROC- DEFS 

::=  <P ROC- HEADINGS 

;  (COMPOUND- BODY'S 
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1 
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*317 

/  <PROC- HEADINGS  ,  <STMi > 

*318 

<PR0C- HEADINGS  = 

PROC  < NAMES  <SUB-ATTRI BUTES 
< FORMAL- PARAMETER- LI STS 

*319 

<SUB- ATTRIBUTES  : : 

= 

*320 

/  REC 

*321 

/  RENT 

*322 

< FUNCTION-DECS  : := 

< FUNCTION-HEADINGS  ; 

<DEC> 

*323 

<FUNCTION-DEFS  : -.= 

< FUNCTION- HEADINGS  ; 

<COMP  JUN'J-  BO 

*324 

/ 

<FUNCTION-HEADING>  , 

<ST TT > 

*325 

< FUNCTION-HEADINGS 

:  :=  PROC  <NA.1ES  <SUB- 

•ATT HI  B U  I : I  > 

<  formal- parameter-  li  s  r  > 

<  IT  EM- TY  P  £  -  DES  C  K I  P  f  i  O  N  > 


*326  <FORMAL-PARAMETEK-LI STS 

327  /  (  :  < FO RMAL- I 0- PARAMET E  K-  L I  k  I  >  ) 

328  /  (  <F0RM4L-I0-PARAMETER- LISTS  : 

<FOKMAL-IO-PARAMETEK-LI  ST  >  ) 

329  /  (  <FORMAL- 10- PARAMETER- LI  ST >  ) 

330  <FOKMAL-IO-PARAMETEK-LISTS 

::=  <FORMAL-LO- PARAMETER- LI S  ,  <NAM;.S 

331  /  <names 

*332  <INLI  ME-  DEO  :  :=  <1 NLI ME- DEC- HEADS  ; 

*333  <INLINE-DEC-H£AD>  ::=  INLINE  <SUb-NAML> 

*334  /  <INLINE-DEC-HEAJ>  ,  <SUB-NAME  - 

*335  <SUB- NAMES  =  <PK0C- LABEL- NAMES 

*3  36  /  <name> 

*337  <STMT-  LI  STS  ::=  <STMT-LIST>  MsFli'S 

*338  /  <STMr-LIST>  <NULL- STMTS  <S  1.'. i> 

*3 39  /  <NULL-STMTS  <STMTS 

*340  /  < STMTS 

*341  < STMTS  : :=  < BALANCED- STMTS 
*342  /  <UNBALANCED-S TMT > 

*343  < B AL AN C E D- S TMT S  :  : =  <BALANCED> 

*344  /  <DI  RECTI VES  <BALANCEi)-S  I'MI'S 

*345  <UNBALANCED-S TMT S  :  :=  <UNBALAMCE!)> 

*346  /  <DIRECTIVES  <UN BALANCED- STMTS 

*347  <UNBALAHCED>  : :=  < LABELS  <UNBALANCED> 

*348  /  <UNBALANCED-I F-STM IS 

*349  /  <UNBAL  ANCED- FOR- STM  I  S 
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*350 

/  <UN BALANCE J-lJHl  LE-5TM:  > 

*351 

<BALANCED>  : 

:=  <LABEL>  <3ALA:iCEU> 

*352 

/  < AS S I G  NME  NT- S TM  T  >  ; 

*353 

/  CBALANCED- FOR- STMT > 

*354 

/  CBALANCED- OH1  L£-STMT> 

*355 

/  CBALANCED- 1  F-ST.MT> 

*356 

/  <CASE-ST.MT> 

*357 

/  <PKOC-CALL-STMT> 

*358 

/  <RETURN-STMr>  ; 

*359 

/  <GOTO-STMT>  , 

*360 

/  <EXIT-STMT>  ; 

361 

/  CSTOP-ST.MT>  ; 

362 

/  <ABORT-STMr>  ; 

*363 

/  BEGIN  <STMT-LIST>  CDI KEC i- COMPOUND- EN 

*364 

<NULL-STMT> 

*  *  > 

*365 

/  BEG L N  <GO'1POONL)-EN;)> 

*366 

COMPOUND- END>  : :=  END 

*367 

/  <LABEL>  COMPOUND-END  ■ 

*368 

CLABEL>  : :  = 

CPROC-LABEL-NAM:.  >  : 

*369 

CASSIGNMENT- 

STMT>  ::=  CTAKGE 1 -LIST /  =  C EXPRESS .  A 

370 

<TARGET-LIST>  ::=  <TAKGE  1'- Li  S  1">  ,  CTAK.D  .  « 

*371 

/  CTARGE1V 

*3  72 

<TARGET>  : := 

<LHS> 

*373 

/ 

CP  ROC-  LABE  L-  N  AM: .  > 

374 

< BALANCED- FO K- S l'MT>  ::=  CFuK- CLAUSE;  CBALANGED-S IM;  > 

375 

/  <FOR-BY>  < BALANCED- STM i > 

3  7b 

/  <FOK-THEN>  CBALANCED-STMi  > 

377 

Cl'NBALANCED- 

FOR- STMT > 

:  :=  < FOR- CLAUS E>  <UN BAL AH C E  J-  S T.M i  > 

376 

/  <FOK- BY>  CUNBALANCED-STMi  > 

379 

/  CFOK-THEN>  CUNBALANCED-STMTa 

380 

<FOK-CLAUSE> 

::  =  <INI TIAL>  <SAF^> 

381 

/  <INITLAL>  C  WH 1  L  E  -  P  H  k  A  S  E  ’>  <SAF;^ 

382  <FOK- BY> 

:  :=  <IN1TLAL> 

383  /  <INITLAL> 

384  /  <INLTLAL> 

385  <FOk-THEN> 

:  :=  <INITIAL> 

386  /  <INiriAL> 

387  /  <INLTLAL> 


<BY-PHRASE>  <SAFE> 
<BY-PHRASE>  CWH1LE- 
< W H I L E -  P H  R AS  E >  <BY- 


PHkASi.  >  CSAFE  > 
PH RASE>  <SAFE> 


<THEN-PHRASE>  <SAFE> 

<THEN- PH RASE>  <WH1 LE-PHRASE>  <SAFL> 
<WHI LE-PHKASE>  CTHEN- PHKASE>  <SAF:.> 
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388  <INIT1AL>  :  :  =  FOK  <NAME>  :  EXPRESSIONS 

389  /  FOK  <LTR>  :  EXPRESSIONS 


390  <BY-PHKASE>  :  :  =  BY  EXPRESSIONS 

391  <THEN-PHRASE>  : :=  THEN  EXPRESSIONS 

392  <WHILE- PHRASES  ::=  WHILE  < BRANCH- FALSES 

*393  <BRANCH-FALSE>  :  :  =  <BI T- FORMULA> 

*394  <BALANCED-WH1 CE- STMTS  :  :  =  <WH1LE-CLAUSE > 

< BALANCED- STMT/ 

*395  <UN B ALAN C K D- WH I L  E- S  TMTS  <WH1 LE- CLAUSE > 

CON  BALANCED- STL 

*396  <WHIL£- CLAUSES  •.  •.=  WHILE  <8KANCH- FALSE’’  <SA 

*397  <SAFE>  : :=  ; 

398  /  ;  ! SAFE  ; 

*399  < BALANCED- 1 F-STM T  >  =  <1 F- PREFIX >  < BALANCE 

*400  <UNBALANCE!)-LF-ST.'IT>  =  <1 F- CLAUSES  • 

*401  /  <1  F-PREr !.'■:>  CUNBAL 

402  <1  F-PREFIXS  :  :  =  <1  F- CLAUSE  >  < BALANCED- STM i  > 

*403  <1 F-CLAUSO  :  :  =  IF  < BRANCH- FALS ES  ; 

*404  <CASE-STM1’S  :  :=  <CASE-BODYS  <C0MP JCN0- EN.>  ■ 

*405  < CASE- BODY >  ::  =  «JASE- CLAUSE >  <CASE-CHO ! CE/ 
*406  /  < CASE.  -  BODY >  <CASE-  CEO ..  C-.  * 

*407  CCASE- CLAUSES  :  :*  CASE  < EXPRESSION.*  ;  BILL  1 

*408  < CASE- CHOICES  =  <CAsE-ALF>  :  <Si"L  > 

409  /  <CASE-ALI>  :  <ST.-ir>  FALL  I' 

*410  <CASE-ALT>  (  <CASE-IND£X-GROUP>  ) 

*411  /  (  DEFAULT  ) 

*412  <CAS E-INDEX- GROUPS 
:;=  <CASE-INDEX> 

*413  /  <CASE-INDEX- GROUPS  ,  <CASE-  INDEX  > 

*414  <CASE- INDEXS  : EXPRESSIONS 

*415  /  < EXPRESSIONS  :  <EXPRESSION 

416  <PKOC- CALL -STMTS 

:  <INVOCAT!ON>  ABORT  <  P  HOC  -  L  A  B  E  L  -  N  .A!  1 K  > 

*417  /  INVOCATIONS  ; 


*418 

<INVOCATI 0N> 

<OUTPUT-LIST>  ) 

*419 

/  <INPUT-LiSr>  ) 

*420 

/  <PKOC- LABE L- NAME > 

*421 

<INPUT-LIST> 

::=  CCALL-PREF1X)  <1  UPUT-PARM) 

*422 

/  <INPOr-LIST>  ,  <1  NPl’  T-PARM) 

*423 

<OUTPUT- LI ST> 

:  :=  <IMPUT-LIST>  :  <OUTPU i  -PARM) 

*424 

/  <CALL-PREFIX>  :  OUTPUT-PARU 

*425 

/  <OUTPUT-LIST>  ,  <0UTP2  T-PA:.. 

*426 

<CALL-PREFI.O 

::=  <PR0C-  LA  BEL-  NAME  >  ( 

*427 

<INPUT-PARM> 

::=  <EXPKS3SI0S> 

*423 

<OL,TPUT-  PAR.!) 

:  :=  <LHS> 

*429 

<return-stmt> 

:  :=  RETUKU 

*430 

<GOTO-STUT> 

:=  GOTO  <PK0C- LABEL- SAME > 

*431 

<EXIT-STMT> 

:=  ELI  I 

432 

<STOP-STMI> 

;=  STOP 

433 

/  STOP  <F>Jn.  12  LA  ' 

434 

CABORT-STMIV 

:  :  =  A BOH: 

*435 

< FORMULA)  : 

•  35 

< FORMULA)  +  <ThKM • 

*436 

/ 

< FORMULA)  -  <TrrM/ 

*437 

/ 

+  <TL'.RM> 

*430 

/ 

-  <TKRM> 

*439 

j 

<TEKM> 

*440 

<ThKM>  ::= 

<TEKM>  *  < FACTOR) 

*441 

/ 

<Tf.KM>  /  <FACroR> 

*442 

/ 

<TEkM>  MOO  <  FA  J  i'Jr\> 

*443 

/ 

<  FACl'Uk) 

*444 

< FACTO K>  : : 

— 

< FACTOR)  **  <PKI MAi\Y > 

*445 

/ 

<PKI:TARY  > 

*446 

<P KI MARY)  : 

•  — 

<INTEGER- LITERAL) 

*447 

/ 

<REAL-LITERAL> 

*448 

/ 

<BIT-LITEKAL> 

*449 

/ 

^CHARACTER- LI TEKAL) 

*450 

/ 

<BOOLEAN-LI  TEhAL) 

*451 

/ 

<POIMTER- LITERAL) 

*452 

/ 

<name:)-vakiable> 

*453 

/ 

<LETTER> 

*454 

/ 

< FUNCTION-CALL) 

455 

/ 

<  I N  T  EG  E  k  -  MA  CHI  ME- P  A  RAM  I.  T  R  k  / 

456 

/ 

<FLOATl  NC.-MACH1 ME- PARAMETER y 
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457 

*458 

459 


/  < FIXED-MACHINE- PARAMETER.* 

/  (  <EXPRESSION>  ) 

/  <CONVERSION>  (  {EXPRESSION)  ) 


*460 

<  BI T  -  FO  RMU  L A>  :  : 

=  <AND- FORMULA> 

*46 1 

/  <OR-FORMULA> 

*462 

/  {xor- formula) 

*463 

/  <EQV- FORMULA> 

*464 

/  <BI T- PRIMARY> 

*465 

/  NOT  < BIT-PRIMARY) 

*466 

< BI T-P RIMARY >  : : 

=  <RELATIONAL-EXPRESSIO:;> 

*467 

/  {FORMULA) 

*468 

<AND- FORMULA)  : : 

=  <BI T- PRIMARY >  AND  {BIT-PRIMARY) 

*469 

/  <AN D- FORMU LA>  AND  < BIT- PRIMARY > 

*470 

<OR- FORMULA)  : := 

{BIT-PRIMARY)  OK  <BI  T- PRI  MARY) 

*471 

/ 

<OR- FORMULA)  OR  {BIT-PRIMArY> 

*4  7  2 

<  X  0  R  -  FO  RMU  LA  >  :  : 

=  <BIT- PRIMARY)  XOR  < BI T- PRIMARY > 

*4  73 

/  {XOR- FORMULA)  XOR  {BI  T-PRl  MARY  ) 

474 

{EQV- FORMULA)  :: 

=  < BIT- PRIMARY)  EQY  <BI  T- P:\IMAKY  ’ 

475 

/  <EQV- FORMULA)  EU>Y  <BL  7- PRL  -> 

*476 

< RELATIONAL- EX PR 

ESS  ION) 

::=  <  FO  RMU  LA> 

{RELATIONAL- OPERATOR)  sr  oRM"L4  > 

*477 

{EXPRESSION)  :  ;  = 

{BIT- FORMULA) 

*478 

<  N  AME D - V  A  R I A  BL  E  > 

: :=  {SUBSCRIPT)  ) 

*4  79 

/  {NAME) 

480 

/  {SUBSCRIPT)  )  {POINT:-.:  > 

481 

/  {NAME)  {POINTER) 

482 

/  {POINTER) 

*483 

{LIV)  {LETTS 

,R> 

*  r  8  4 

/  A 

*485 

/  B 

*486 

/  c 

*487 

/  D 

*488 

/  F 

*489 

/  M 

*490 

/  N 

*491 

/  P 

*492 

/  R 

*493 

/  8 

*  4  9  4 

/  T 

*495 

/  u 

*496 

/  v 

*497 

/  w 

498 

<POL  NTER>  :  :«  <NAME> 
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499 


V  <F0 RMULA>  ) 


*500  <SUBSCRI PT>  ::=  <PREFIX>  <FORMULA> 

*501  /  <SUBSCRI  FT>  ,  < FORMULA) 

*502  <PREFIX>  <NAME>  ( 

503  /  <POINTER>  ( 

*504  <LHS>  ::=  <NAMED-VARI ABLE> 

505  /  <PSEL'L)0-VARI ABLE> 

506  <PSEUDO-VARIARLE> 

::=  BIT  (  <TARGET>  ,  <FORMULA>  ,  < FORME LA >  ) 

507  /  BYTE  (  <TARGET>  ,  <FORMULA>  ,  < FORMULA)  ) 

50B  /  REP  (  < NAM E D- V A R I A 6 E E >  ) 

*509  <FUNCTION-CALL>  ::=  <1 NVOCAT1 ON) 

510  /  <INTKlNSIC-FUNCTLON-CALL) 


51 1  <1 N TRINSIC- FUNCTION- CAL L> 

512 
51  3 

514 

515 

516 

517 

518 

519 

520 

521 


:=  <LOC-FUNCriON> 

/  <nex!- function) 

/  <BI T- FUNCTION) 

/  < BYT E-  FU NC 1 1 0  N ) 

/  <SHI FT- FUNCTION) 

/  <ABS-FUNC  I  LOO 
/  <SIGN-  F'JNC  I L  ON> 

/  <  S 1 Z  E  -  FU  N  C  T  l  O  N  > 

/  <bocnos-fenci lon> 

/  <NVDbEN- FUNCTION  • 

/  <STATiJS-  INVERSE-  FUNC  II  Oi 


522  <LOC- FUNCTIONS  :  .=  LOC  (  <NAMKD- VARIABLE)  ) 

523  <NEXT- FUNCTION)  ::=  NEXT  (  <FORMULA>  ,  <FjkMNLA)  ) 

524  < BIT- FUNCTION) 

::=  BIT  (  EXPRESSION)  ,  < FORMULA)  ,  < FORMULA '  ) 

525  <BYTE- FUNCTION) 

::=  BYTE  (  < FORME LA)  ,  < FORMULA)  ,  < FORMULA)  ) 

526  <SHI FT- FUNCTION) 

::=  <S HI  FT- DIRECT I ON)  (  <EXPRESSLON>  ,  <FOkMELA)  ) 

527  <SHI FT -DIRECTION)  ::=  SHIFIL 

528  /  SHI  FIR 


529  <ABS- FUNCTION)  ::  =  ABS  (  < FORME LA)  ) 

530  <S I GN- FUNCTION)  ::=  SGN  (  < FORME LA)  ) 

531  <SIZE- FUNCTION)  : :=  <S1ZE-TYPE)  (  < FORME LA)  ) 

532  /  <SIZE-TYPl>  (  <TY PE-NAME )  ) 
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533 

<Si^E-TYPE>  ::=  BITS 14^ 

534 

/  BYTESI 4 E 

535 

/  WORDSI2E 

536 

<BOUNDS- FUNCTIONS 

: :=  <WHICH- BOUNDS  (  <NAME> 

,  < FORMULAS  ) 

537 

<WHICH-BOUND>  =  LBOUND 

538 

/  U BOUND 

539 

<NWDSEN- FUNCTIONS  : :=  NWDSEN 

(  < NAMES  ) 

540 

/  NWDSEN 

(  (TABLE-TYPE 

541 

<STATUS-INVEkSE- FUNCTIONS 

::=  FIRST  (  <STATUS-INVERSE 

-ARGUMENT)  ) 

542 

/  LAST  (  (STATUS -INVERSE- 

ARGUMENT >  ) 

543 

<STATUS  - 1 NVEkSE- ARGUMENT')  :  :  = 

< FORMULAS 

544 

/ 

<1 T  EM- TYPE- N 

545 

<CONVERSI  ON>  :  :=  (*  CITEM-TYPE-OESCRL  P  II  IN’ 

546 

/  (type-names 

547 

/  REP 

548 

/  B 

549 

/  c 

550 

/  F 

551 

/  p 

552 

/  5 

553 

/  u 

554 

<NAME-LI ST>  <NAME> 

555 

/  <NAME-LIST>  , 

<NAME  > 

556 

(RESERVED-WORDS  : :=  ABORT 

557 

/  ABS 

558 

/  AND 

559 

/  BEGIN 

560 

/  bi  r 

561 

/  BITSI2E 

562 

/  BLOCK 

563 

/  BY 

564 

/  BYTE 

565 

/  BYTESIZE 

566 

/  CASE 

567 

/  COMPOOL 

568 

/  CONSTANT 

569 

/  DEF 

570 

/  DEFAULT 

571 

/  DEFINE 

572 

/  ELSE 

573 

/  END 

574 

/  EQV 

575 

/  FALL  THRU 

576 

/  FALSE 
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577 

/ 

FI  KST 

578 

/ 

FOR 

579 

/ 

GOTO 

580 

/ 

IF 

581 

/ 

INLINE 

582 

/ 

INSTANCE 

583 

/ 

ITEM 

584 

/ 

LABEL 

585 

/ 

LAST 

586 

/ 

L BOUND 

587 

/ 

LIKE 

588 

/ 

LOC 

589 

/ 

MOD 

590 

/ 

NEXT 

591 

/ 

NOT 

592 

/ 

HULL 

593 

/ 

NWDSEN 

594 

/ 

OR 

595 

/ 

OVERLAY 

596 

/ 

PARALLEL 

597 

/ 

POS 

598 

/ 

PROC 

599 

/ 

PROGRAM 

600 

/ 

REG 

601 

/ 

REF 

603 

/ 

REN  1 

603 

/ 

REP 

604 

/ 

RETURN 

605 

/ 

SON 

606 

/ 

SHI F  TL 

607 

/ 

S  H 1  F I  k 

608 

/ 

START 

609 

/ 

STATIC 

610 

/ 

STATUS 

61  1 

/ 

STOP 

612 

/ 

TABLE 

613 

/ 

TERM 

614 

/ 

THEN- 

61  5 

/ 

TRUE 

616 

/ 

U BOUND 

617 

/ 

WHILE 

618 

/ 

words: 

619 

/ 

XOK 

*620 

<RELATIONAL-OPEKATOK>  ::=  = 

*621 

/  <> 

*622 

/  < 

*623 

/  > 

*624 

/  <  = 

*625 

/  >  = 

626  <BIT-LITEKAL>  <1 NTEGER- LI TERAL>  B 

<CHARACTER-LITER,iL> 
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*627 

< BOOLEAN -LITERALS  : :  =  TRUE 

*628 

/  FALSE 

*629 

<POINTER-LITEKAL>  ::=  NULL 

630 

<DI RECTI VE>  : := 

<COMPOOL- DIRECTIVES 

631 

/ 

<COPY- DI RECTI VE> 

632 

/ 

<SK1 P-DIRECTIVE> 

633 

/ 

<B EG IN- DIRECTIVES 

634 

/ 

<END- DIRECT IVES 

635 

/ 

<LINKAGE- DIRECTIVES 

636 

/ 

<TKACE-DI RECTI VES 

637 

/ 

<INTERFERENCE- DIRECTIVES 

638 

/ 

<REDUCIBLE- DIRECT I VES 

639 

/ 

<NOLI ST- DIRECTIVES 

640 

/ 

<LI ST-DI RECTL VES 

641 

/ 

<EJECT- DIRECT! VES 

642 

/ 

< BASE-DIRECTIVES 

643 

/ 

<1 S BASE- DIRECTIVES 

644 

/ 

<DROP- DIRECTIVES 

645 

/ 

<  L  E  FT  R I G  H  T  -  D I R  E  C  T I V  l.  S 

646 

/ 

<RE AR  RANG  E - DI R  E  CT  L  V  E  S 

647 

/ 

<INITLALIZE- DIRECTIVE 

648 

/ 

<ORDER- DI RECTL  VES 

649 

< COM POOL- DIRECTIVE) 

::=  ICOMPOOL 

<compool-direct:.  ve-l:  s  :  >  , 

650 

CCOMPOOL- DIRECTIVE- LI ST> 

651 

/  CCOMPOOL- 

FILE-NAMES  <COMP00u-DECL \R 

652 

/  CCOMPOOL- 

DECLARED-N.’CIE-LI  ST  > 

653 

/  (  ) 

654 

/  (  <compool-file-na:l:>  > 

655 

< COM POOL- DECLARED- NAME- L [ S l > 

::=  <COMPOOL- 

DECLARED- NAMES 

6  56 

/  <COMPOOL- 

DECLARED- NAME-LIS I>  , 

<COMPOOL- 

DECLARED- NA.'ES 

657 

<COMPOOL- DECLARED- N.‘C1E>  ::=  <NAME> 

658 

/  <TY PE- NAMES 

65« 

/  <PROC-LABEL-N 

660 

/  (  <TYPE-NAME  > 

661 

/  (  <P ROC- LABEL 

662 

/  (  < NAMES  ) 

663 

<  COM  POOL-  FI  L£-NAME>  ::=  <CHARAC  l'EK-LI  TEKA 

664 

<COPY -DIRECTIVE >  ::=  I  COPY  <CrtARACTEK- LIT 

665 

<SK1P-DI RECTIVE>  ::=  1SRLP  ; 

666 

/  '.SKIP  <LT*>  , 

667  <BEGIN-DIRECTLVE>  ::=  1BEG1N  ; 

668  /  !  BEGIN1  <LTK>  ; 

669  <END- DIRECTIVE)  ::=  ! END  ; 

670  <LI NKAGE-DI RECTI VE>  ::=  J LINKAGE  <SYMBOL-LIST'>  ; 

671  <TRACE- DI RECTI VE> 

:  :=  1  TRACE  (  < FORMULA)  )  <NA1IE-LIST>  ; 

6  72  /  I  TRACE  <NAME-LI ST> 

673  <INTERFERENCE-DI RECTI VE> 

::=  [INTERFERENCE  INTERFERENCE- CONTROL)  ; 

674  INTERFERENCE- CONTROL) 

:  :=  <NA>1E>  :  <NAME> 

675  /  <INTERFERENCE- CONTROL>  ,  <NAME> 

676  <REDUCI BLE- DI RECTI VE>  ::=  ! REDCCI BEE  ; 

677  <N0LI ST- DIRECTIVE)  ::=  INJLISI  ; 

678  <LIST-DIRECTIVE>  ::=  1LIST  ; 

679  <EJ  EC  I- DI RECT I VE>  ::=  1EJECI  ; 

680  <  BASE- DIRECTIVE)  ::=  !  BASE  <NA!1E>  <1  NTEGER- LI  TEts.-C.)  ; 

681  <IS BASE- DIRECTIVE;  ::=  !  I S  BAS  E  <  N  A)  IE  XI N  T  EG  E  k  -  L I  T  E  R  A L  >  , 

682  <DR0P-DI  RECTIVE)  ::=  !  DROP  <  1  NT  EG  E  R-  L I T  E  K  A  L  >  , 

683  <LEFTRIGHT-DIRECITVE>  ::=  !  LEFTRiGH:  ; 

684  <REARRANGE- DIRECTIVE)  ::=  ! REARRANGE  ; 

685  <1 NITLALI ZE-DI RECTIVE)  ::  =  !INI T I ALICE  ; 

686  <0KDEK-DIRECTIVE)  •  :=  ! OKDEr.  ; 
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Appendix  „ 


System  Maintenance  Guide 

This  appendix  describes  the  structure  and  organizat  i  >  . 
of  JATS.  The  purpose  of  this  appendix  is  to  provide  tu  • 
necessary  information  to  the  maintenance  programmer  to  all  ■>.; 
modification  of  the  system.  The  overall  system  will 
briefly  described  followed  by  a  system  structure  chart, 
description  of  each  subroutine,  and  a  list  of  system,  err  >r 
s  ta cements . 

JATS  uses  the  LK  parser  generator  system  t  .>  construct  i 


parse  tree  of  the  input  J73 

source  program. . 

Inis 

p  a  r  s  e 

is  then 

translated  so  that 

it  represents  an 

egai-. 

'  d  i  C  "it. 

source 

program.  Finally 

,  tiie  terminal 

■1  >Je  s 

a  r  e  o 

using  a  prettyprint  format.  The  structure  of  JATS  can 
therefore  be  grouped  into  three  functional  module*-: 
(1)  parser  module,  (2)  translation  module,  am.: 
(3)  prettyprint  module. 

The  parser  module  was  designed  fro.'.  the  LK  parser 
generator  system  and  the  parsing  algorithms  were  take  , 
directly  from  LR .  Appendix  A  contains  a  brief  description 
of  LR  and  the  data  structures  that  support  the  parsin0 
algorithms.  There  is  one  modification  to  the  parsing 
routines  to  accommodate  the  J73  grammar.  During  the  parsin^ 
loop,  a  check  is  made  in  certain  states  of  the  parser  to  set 
a  flag  which  indicates  whether  the  parser  is  process!  g 


72 


! 


executable  statements  or  declarations.  Inis  flag  is 
within  the  scanner  to  return  the  correct  token  dor i 
scanning  of  <name>s.  The  major  additions  to  the  parser 
the  scanner  and  the  semantic  processor.  The  scanner  return-, 
the  tokens  of  the  input  stream  to  the  parser.  It  consist  -  * 
of  a  number  of  subroutines  which  will  be  discussed  later. 
The  semantic  processor  constructs  the  parse  tree  during  t  n- 
reduction  processes.  The  subroutines  that  support  tin- 
semantic  processor  will  be  discussed  later.  One  other  are  . 
of  interest  is  the  use  of  a  "heap"  for  dynamic  a  1 L  oca  t  i  on  ■ 
the  nodes  and  elements  of  the  tree. 

The  translation  module  processes  the  pa:  sc  tree  us  1  : 
the  language  production  numbers  that  were  used,  t  >  construe  • 
each  internal  node.  Worth  noting  during;  the  tr  S::sl  > :  :  u 
process  is  the  reclamation  and  real  location  of  (leap  spue-.- . 

A  list  of  available  heap  space  is  maintained,  by  Irni'v,  :h 
spaces  together .  Nodes  of  the  tree  that  are  dele t ed  -o  ■ 
also  made  available  for  reallocation  thr  -ugh  liuru  : 
of  available  nodes  using  an  overla/ed  dam  struct  n  -  . 

The  prettyprint  module  simply  outputs  tin.  le 
terminal  nodes,  of  the  parse  tree  and  uses  the  symbol s  t  ■ 
control  the  formatting  of  the  resulting  Ada  program. 

A  system  structure  chart  is  spread  across  figures  1  J  , 
13,  and  14.  A  brief  description  of  each  subroutine  follow- 
the  system  structure  charts.  Al  s  <  included.  in  tun, 
appendix,  is  table  IV  which  describes  the  possible  sys  te 
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.1  ATS 


ADD1  HOPE .  Local  to  procedure  TRANSLATE.  L;$eU  Jar. 
the  translation  process  to  create  a  new’  terminal  no 
consisting  of  the  terminal  symbol  TERM ' CODE ,  it  adds  the  n 
element  to  the  current  node.  The  new  element  is  insert 
immediately  after  the  element  pointed  to  by  PTR.  Updat 
the  global  variable  NEXT’ NODE. 

CHANGE 1  NODE .  Local  to  procedure  TRANSLATE.  Chang 
the  terminal  symbol  at  the  node  identified  by  the  ele:.e 
pointed  to  by  PTK  to  TERM' CODE. 

CHAR' STRING .  Local  to  procedure  SCAN .  Used  t>  sc 
<character-literal>s  during  the  parsing  process.  Const  rue 


a  new  element  of 

the  termin-.l 

no  d.e 

to  identir 

<charac  ter- li terai>  . 

Upda tes 

tile 

olohol  Vi 

i  V  L  i 

NEXT*  STRING  and  STRING(NEXT' S TkI NG; .  Ketirus  the  t  >k 
number  of  <charac ter- 1 i teral >  in  SCAN’TOK. 

CHAR'VAL.  Local  to  procedure  N'."-'.BLr.  Fuuct  i>n  u- 
during  the  process  of  scanning  numbers  t  >  ret  nr  i  the  Va ! 
of  the  digit  Gil. 

COMMENT.  Local  to  procedure  SCAN .  Used  to  sc  i.i 
comment . 

DEC 1  HEAD .  Global  boolean  function.  Used  during  t 
parsing  process.  Returns  the  value  TRUE  if  the  toke 

IN’TOKEN,  is  the  start  of  a  declaration.  If  IN'TOKEN  is 
<name>  then  the  global  CUR1 TOKEN  is  changed  to 

<proc- label-name> . 


DELETE '  NODE .  Local  to  procedure  TRANSLATE.  I  s-_  : 
during  translation  to  delete  the  node  element  immediate!/ 
following  the  element  identified  by  PTK  and  culls 
DELETE ' SUBTkEE  with  the  node  number  at  the  deleted  el  erne  . 
Updates  the  global  variable  FKEE'PTk. 

DELETE 1  SUBTREE.  Local  to  procedure  DELETE '  Nudr. .  P; : 
is  a  recursive  procedure  that  deletes  all  nodes  and  element  - 
from  the  parse  tree  as  a  result  of  deleting  the  node 
NODE ' NUMBER.  Updates  the  global  variables  NEE  T ' NODE  and 
FREE' PTK. 

DIGIT.  Local  to  procedure  SCAN.  ii.'>lein  t  me:,  i  •  >: 
which  returns  cue  value  TRUE  if  CH  is  a  digit. 

DIRECTIVE .  Local  to  procedure  SC.-.N.  Used,  t  ■  sc  m 
directives.  Returns  the  proper  token  number  in  SC-.N  ’  1  uE  . 

DO*  REDUCT .  Global  procedure.  Used  during  t'n  pursing 
process  to  perform  a  reduct  ion  based  on  the  i-i  ig  m  ■ 
production  PROD’NUM.  Calls  SEMANTIC  and.  p  lslies  t'n  n-  ; 
information  onto  the  parsing  sticks.  Updates  the  globi ! 
variables  STACK’ PlK  and  CUR'ETATE. 

DO '  TRAN .  Global  procedure.  Used  during  the  pit's  ip 
process  to  perform  a  transition  to  NEW' STATE.  Stacks  the 
current  information  onto  the  parsing  stacks  and  calls  SC'-.N 
for  a  new  CUR' TOKEN.  Updates  the  global  variables  CUK'Slal. 
and  CUR’ TOKEN. 


DOUBLE 1  MARK .  Local  Co  procedure  SCAN.  Cnecas  i:  t 
current,  token  being  scanned  might  be  a  double  character 
symbol,  such  as  <>.  Returns  the  correct  token  number  .»■ 
SCAN'TOK  for  either  case. 

ERROR .  Glocal  procedure.  Used  during  the  pars  in. 
process  to  output  information  regarding  the  current  .statu- 
of  the  parser  when  a  syntax  error  has  been  detected.  .  Sc  - 
the  global  variable  ERR'  FLAG  to  the  value  Trdh.  wnioh  halts 
the  parser  and  translator  system. 

FI N 0 1  REDUCT .  Global  procedure.  Faucet  vi  used  dur:  ; 
the  parsing  process  to  find  the  proper  reduction  to  per  for  .. 
based  upon  CSTATE  and  CTOKEN. 

FI NDTOK .  Local  to  procedure  SLAG.  Used  darLig  t  u 
scanning  of  terminal  symbols.  Uses  TDK '  SYMBOL  an  I  LUNNl'u  ' 
match  the  current  symbol  with  the  terminal  svt.jols  if  d  / ;  , 
if  a  match  is  found  the  value  of  the  token  nun. he r  1  ■ 
returned  as  RET' VALUE. 

FIND'  TRAN .  Global  procedure.  Fu-uti  vi  used  during  thi 
parsing  process  to  find  the  proper  transition  based  u;  »  . 
CSTATE  and  CTOKEN. 

GET 1  CHAR .  Local  to  procedure  SCAN.  Ret  urns  the  m-  -:t 
character  of  the  input  stream  as  CH ,  and  echochecks  the 
input  line  images.  Sets  EOF' FLAG  and  clears  NEXT ' CHAR . 

INIFAL.  Global  procedure.  Initialises  various  -Ion..'. 


SO 


variables  and  data  structures. 

LOOKUP .  Global  procedure.  Uses  the  global  variable 
SYMBOL  to  find  the  symbol  table  entry  for  the  <name>  that  i ■ 
contained  in  SYMBOL  with  a  length  of  SYM' LENGTH,  a  glob,;! 
variable.  If  an  entry  is  found,  ENT KY  '  P  T  K  contains  the 
pointer  value  of  the  entry  and  FOUND  is  TRUE.  If  an  eut  ry 
is  not  found,  the  symbol  is  entered  in  tne  symbol  table  and 
ENTRY'PTR  contains  the  pointer  value  of  the  new  entry  and. 
FOUND  is  FALSE.  If  a  new  entry  is  made  tie  global  varinbU 
NEXT' SYMBOL  is  updated. 

MARK.  Local  to  procedure  SCAN’ .  Boolean  function  t  > 
determine  if  the  current  character  of  the  input  stream  i  > 
mark,  or  seperator .  Returns  TRUE  is  the  char  ic  ter 
mark . 

MOVE' PfR.  Local  to  procedure  TrANSLATu .  Used  da:  .  : 
translation  to  move  the  element  pointer  of  a  node,  FT.-. ,  th> 
number  of  positions  specified  by  COL'N.. 


NAME  1  KESvJORD. 

L  O  C  ri  1  t  .) 

urooo>l  jr S L./i.i . 

U sed  to  SC ; 

<name>s  and  reserved 

words  . 

Once  the  s/mh 

ml  boo  bee 

scanned,  if  FINUTOK  returns  a  value  0  then  it  is  a  <:iaue>. 
Builds  the  global  variable  SYMBOL  and  SYM ' LENGTH .  Returns 
the  correct  token  number  as  SCAN'TOK.  May  reset  the  globa’. 
variable  STMT ' SCAN ' FLAG . 

NEWP .  Global  procedure.  Function  which  returns  ih- 
next  available  heap  space  pointer  address  for  a  da  i 
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structure  of  the  given  SIZE.  Updates  the  global  variunii 
FREE ' PTR  or  NEXT’ HEAP  as  necessary. 

NUMBER .  Local  to  procedure  SCAN.  Used  to  scan  numbers 
and  returns  the  proper  token  number  as  SCAN’ TOR  and 
constructs  a  node  that  contains  the  value  of  the  appropriate 
literal . 

PRETTY ’ PRINT .  Local  to  procedure  PRlNT'ADA.  Used  t  - 
output  the  terminal  symbol  contained  in  the  terminal  nod... 
PRINT 'NODE. 

PRI NT ' ADA .  Global  procedure.  Recursive  procedure- 
which  traverses  the  subtrees  of  NODE' NUMBLa  and  calls 
PRETTY 'PRINT  when  a  terminal  node  is  reached  .  Als>  outp:’-. 
warnings  that  certain  sections  of  code  have  not  been  fully 
translated.  Sets  and  resets  the  global  varii.lv 

LAST' THAN' FLAG . 

PRINT*  NODE.  Glooai  procedure.  Utility  procedure  t '  1  ■ .  • 
outputs  the  contents  of  the  node  NODE ' NUMBER . 

PRINT  'STRINGS .  Glooai  procedure.  Util  it  y  precede:'" 
that  outputs  the  <charac t er-  1  i tera  1  >s  th.-.r  h -ivc  heel  parsed. 

PRINT1  SYM1  TAB.  Global  procedure.  Ur  .  iity  procedure 
that  outputs  the  contents  of  the  symbol  tn>K. 

PRI NT 1  TREE .  Global  procedure.  Recursive  procedure 

and  calls  PRINT' NODE  to  output 


that  traverses  the  parse  tree 
the  entire  parse  tree. 
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SCAN .  Global  procedure.  Scans  the  input  and  re 
the  token  numbers  as  SCAN' TOR.  Creates  a  new  terminal 
each  time  it  is  called  and  updates  the  global  var 
NEXT' NODE. 

SEMANTIC .  Global  procedure.  Used  during  tine  pa 
process  to  construct  a  new  node  based  on  the  lan 
production  PROD’NUM.  Also  enters  the  SYM' CLASS  values 
the  symbol  table  and  updates  the  global  variables 
NEXT ' NODE ,  and  NEW ’TREE ' PTH . 

SWAP 1  NODES .  Local  to  procedure  TRANSLATE.  Used  d 
the  translation  process  to  swap  the  two  node  element  s 
immediately  follow  the  element  pointer  to  by  ihr.  P 
moved  to  point  to  the  new  element  that  foil  rw-.-.  t'u  e  1 
that  was  initially  pointed  to  by  ?T:\. 

TRANSLATE.  Local  t  >  procedure  TkAN'TkEE.  Com.  r  •! 
translation  process  at  each  node  TK-iN '  NdL'E .  Set 
TRAN' FLAG  for  each  n-.de  L.nat  is  translated .  May  cre-c.  v 
nodes  and  elements. 

T KAN ' TREE .  Global  procedure.  Recursive  procedure 
to  traverse  the  parse  tree  during  translation. 
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Table  IV 


System  Errors 


Error 

Number  Cause/ Required  Changes 

1  Parsing  stack  overflow 

Increase  the  value  of  MAX' STACK 


2 

3 


5 

6 


SYM' STORE 'TAB  overflow 

Increase  the  value  of  MAX  1 SYM' S  FOK 

HEAP  overflow 

Increase  the  value  of  MAX’ HEAP 


TREE  overflow 

Increase  the  value  of  MAX ’NODES 
STRING  overflow 

Increase  the  val  ue  of  MAX  '  S T.\l  NGS 

STRING' S  TORE  overflow 

Increase;  the  value  of  'LAX' S  THING  '  S 


8- 


Appendix  D 


JATS  User  Guide 

The  purpose  of  this  appendix  is  to  provide  s 
guidance  for  dATS  users.  The  system  itself  is  very  easy 
use;  however,  there  are  several  limitations  that  the  u 
must  adhere  to  for  JATS  to  work  properly.  As  shown  in  t  : 
I,  there  are  several  elements  of  J7d  that  have  modit 
def ini t ions . 

One  other  area  that  the  user  must  prepare 

translation  is  the  identifiers  or  <na:r.e>  s  of  the 
program.  As  JATS  is  currently  implemented ,  <nam._->s  that 
to  be  translated  must  not  be  Ada  reserved  wards.  The  ot 
limitation  with  respect  to  <name>s  is  the  use  of  the  sin 
quote  within  the  identifiers.  The  use  of  tie  single  qu 
must  conform  to  the  rules  of  the  use  of  the  underscore 
Ada.  This  requires  that  the  single  quote  he  proceeded 
followed  by  eitner  a  digit  or  letter  and  the  single  qu 
cannot  end  the  <name> .  Also,  the  use  of  the  cm.  ir  sign 
not  allowed  since  it  does  not  trmsiate  to  any  eq  rival 
element  of  Ada.  These  limitations  can  be  removed  when  .! 
is  modified  to  become  an  interactive  system  to  a’.  1  vw 
user  to  rename  an  identifier  when  necessary. 

With  these  limitations  taken  care  of,  the  J7d  prog 
can  be  translated  with  JATS.  On  the  AFWAL/AA  DecSyster- 
JATS  can  be  run  witii  the  following  command: 


85 


•RUN  JATS [ 5600 ,113] 
*<file  name> .<extension> 


JATS  will  respond  with  an  asterisk  as  a  prompt  for  the 
name  at  which  time  the  user  should  respond  with  a  valid 
with  an  extension  of  J7d. 

JATS  will  create  two  output  files:  (1)  J.-Yio.  LSI 

(2)  <£ile  name>  .ADA.  JATS.LST  will  contain  a  listing  o 
input  program  and  any  information  messajes  thv 
generated.  The  second  file  is  the  translated,  vrintu  o 
program  and  will  have  the  same  :  tie  name  with  ex: 

of  ADA.  This  file  will  contain  warning  me<s.:g^s  i  n : 
sections  of  code  that  were  not  translated. .  lues,  set 
will  be  bracketed  by  the  fol  Lowing  me.-sage  . 


W  A  ti  X 


THE  CODE  SEC  TWEEN  THIS  BxAICKEJ  AND  To:  : 

B RACKS  I  /lAY  NOT  BE  r  E-EY  ih.AN:  C  . 


THE  CODE  BETWEEN  THIS  BRACKS  1  AND  THE  Ptv.Yl  >  h 
BRACKET  MAY  NOT  BE  FELLY  TxANSLM  J) 

- - - - - - - - - - iaKi’ii.et - - - - - 

JATS  has  been  designed  to  process  large  program..- 
does  have  some  limitations  on  sine.  If  a  message  const 
of  a  JATS  system  error  appears  at  the  terminal  while 
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running,  then  one  of  the  size  lini tations  has  been  exeee 
and  JATS  will  nave  to  be  modified  and  recompiled.  If  t 
occurs,  notify  the  maintenance  programmer. 

An  example  J73  program  and  its  translated  version 
included  in  Appendix  E. 
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X  AD-A100  881  AIR  FORCE  INST  OF  TECH  HR I GHT-PATTERSON  AFB  OH  SCHOO— ETC  F/6  9/2 
JOVIAL  t J73)  TO  ADA  TRANSLATOR  SYSTEM. (U) 

DEC  80  R  L  BR020VIC 

UNCLASSIFIED  AFIT/6CS/EE/B0D-5  NL 
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Appendix  E 
Example  Programs 


J73  Version 


START  PROGRAM  TSTPGM; 

BEGIN 

ITEM  TEST' NAME  C  3; 

ITEM  TEST' FLAG  B  1 ; 

ITEM  TEST' CHAR  C; 

ITEM  TEST 'NUMBER  U  3; 

ITEM  TEST' NUM  S; 

HERE : 

TEST 'NUMBER  =  3; 

CASE  TEST' NUMBER; 

BEGIN 

(DEFAULT)  :  TEST' FLAG  =  FALSE; 
(1  )  :  TEST' FLAG  =  TRUE; 

(2:3.5)  :  TEST 'FLAG  =  TRUE; 

END 

WHILE  TEST 'NUMBER  *  3 ; 

TESTPROC; ; 

IF  TEST' NUMBER  =  5; 

GOTO  HERE; 

PROC  TESTPROC; 

IF  TEST 'FLAG; 

BEGIN 

TEST 'NAME  =  'ABC' ; 

TEST' NUMBER  =  5; 

END 

END 

TERM 
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Ada  Version 


PROCEDURE  TSTPGM  IS 

TEST_NAHE  :  STRING  (1  . .  3  )  ; 

TEST_FLAG  : 

— . WARNING . 

THE  CODE  BETWEEN  THIS  BRACKET  AND  THE  FOLLOWING 
BRACKET  MAY  NOT  BE  FULLY  TRANSLATED 


B  1 


THE  CODE  BETWEEN  THIS  BRACKET  AND  THE  PREVIOUS 
BRACKET  MAY  NOT  BE  FULLY  TRANSLATED 

. . -WARNING . 

TEST_CHAR  :  STRING  (1  . .  1  )  ; 

TEST_NUMB£K  :  INTEGER  RANGE  0  . .  2  **  (  3  )  -  1  ; 
TEST_NUM  :  INTEGER  ; 

PROCEDURE  TESTPKOC  IS 
BEGIN 

IF  TEST__FLAG  THEN 

TEST_NAME  "ABC"  ; 

TEST_NUMBER  :«  5  ; 

END  IF  ; 

END  ; 

BEGIN 

«  HERE  »  TEST_NUMBEK  :=  3  ; 

CASE  TEST_NUMBER  IS 

WHEN  OTHERS  =>  TEST_FLAG  :=  FALSE  ; 

WHEN  1  =>  TEST_FLAG  :=  TRUE  ; 

WHEN  2  ..  3  1  3  ->  TEST_FLAG  :=  TRUE  ; 

END  CASE  ; 

WHILE  TEST_NUMBER  =  3  LOOP 
TESTPROC  ; 

END  LOOP  ; 

NULL  ; 

IF  TEST_NUMBER  =  5  THEN 
GOTO  HERE  ; 

END  IF  ; 

END  ; 
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